I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.
clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.
I propose to re-format Carpet's source code via clang-format.
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
Please comment.
-erik
On 3 Jul 2015, at 23:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.
clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.
I propose to re-format Carpet's source code via clang-format.
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
Please comment.
Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences.
I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again.
With the above considerations, is it worth doing this?
On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 3 Jul 2015, at 23:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.
clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.
I propose to re-format Carpet's source code via clang-format.
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
Please comment.
Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences.
I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again.
With the above considerations, is it worth doing this?
Yes, it definitively is. Not having to worry about indentation and formatting while coding frees the mind; it is a transformative experience.
-erik
On 4 Jul 2015, at 17:06, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 3 Jul 2015, at 23:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.
clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.
I propose to re-format Carpet's source code via clang-format.
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
Please comment.
Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences.
I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again.
With the above considerations, is it worth doing this?
Yes, it definitively is. Not having to worry about indentation and formatting while coding frees the mind; it is a transformative experience.
I just press TAB in emacs to make sure the indentation is correct; it's not something I ever really think about. After reading Roland's email, I'm more and more concerned that a large-scale reformatting of an existing codebase with several branches owned by different people is going to cause a fair amount of pain. For a new project, I would definitely use such a system, and when new code is added to an existing project, but I'm not sure it's worth the trouble it will cause for Carpet.
Yeah, that's what I thought in the beginning -- code formatting is all about indentation, which is handled by the tab key. But it turns out, it isn't. I only noticed after using clang-format for some way. Code formatting ties up part of your brain, every time you type a character, you have to ask yourself "do I need to insert a space", "do not need to insert a line break", "should I join these two lines again", "does this comments need re-formatting", "should I line-wrap this lengthy expression differently", "how do I make these lines line up nicely", etc.
With clang-format -- none of this. You type in the content you want, you insert spaces where absolutely necessary, you save, and when you look again, the code looks nice. And you can relax in the knowledge that this formatting is a projection -- there's no "other way" that maybe might look better.
Also, clang-format doesn't indent namespaces the way the tab key does, and it doesn't make errors. Clang-format is the complete separation of form and content, and you only have to care about the latter. Think of it as latex: You type the text, and it will look well-formatted without requiring any manual input. You may think that latex isn't necessary and that manually formatted text will look just as nice -- and you're probably right, in almost all cases manual formatting would look nice enough to do the trick. But there is a fundamental difference between latex and manual formatting, and it's good to have it.
So: Yes, this is worth it.
Regarding various versions of clang-format: There are (of course) also many options you can set, although I just go with the default, which is very good. Yes, there are probably difference between versions (improvements, e.g. for handling template arguments). I'm sure we could settle on a standard version, or a standard set of options.
-erik
On Mon, Jul 6, 2015 at 5:56 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 4 Jul 2015, at 17:06, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 3 Jul 2015, at 23:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.
clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.
I propose to re-format Carpet's source code via clang-format.
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
Please comment.
Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences.
I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again.
With the above considerations, is it worth doing this?
Yes, it definitively is. Not having to worry about indentation and formatting while coding frees the mind; it is a transformative experience.
I just press TAB in emacs to make sure the indentation is correct; it's not something I ever really think about. After reading Roland's email, I'm more and more concerned that a large-scale reformatting of an existing codebase with several branches owned by different people is going to cause a fair amount of pain. For a new project, I would definitely use such a system, and when new code is added to an existing project, but I'm not sure it's worth the trouble it will cause for Carpet.
-- Ian Hinder http://members.aei.mpg.de/ianhin
On one hand, clang-format ought to be really good because it can leverage the clang parser and understand the code as well as the compiler. Other tools have to re-engineer the whole process and may not get it exactly right. I'm rarely completely happy with auto-format, and because of that I only ever apply it to small areas of code at a time.
On the other hand, there is a potential version issue. I just formatted a simple code with two versions of clang-format I had installed on my laptop and got different results. The older version messed up the formatting of a C++11 initializer. While the C++11 issues are probably not going to be a problem going forward, other issues might crop up. I could easily imagine bits of formatting changing back and forth as two developers with different versions of clang updated the source.
Cheers, Steve
On 07/07/2015 10:51 AM, Erik Schnetter wrote:
Yeah, that's what I thought in the beginning -- code formatting is all about indentation, which is handled by the tab key. But it turns out, it isn't. I only noticed after using clang-format for some way. Code formatting ties up part of your brain, every time you type a character, you have to ask yourself "do I need to insert a space", "do not need to insert a line break", "should I join these two lines again", "does this comments need re-formatting", "should I line-wrap this lengthy expression differently", "how do I make these lines line up nicely", etc.
With clang-format -- none of this. You type in the content you want, you insert spaces where absolutely necessary, you save, and when you look again, the code looks nice. And you can relax in the knowledge that this formatting is a projection -- there's no "other way" that maybe might look better.
Also, clang-format doesn't indent namespaces the way the tab key does, and it doesn't make errors. Clang-format is the complete separation of form and content, and you only have to care about the latter. Think of it as latex: You type the text, and it will look well-formatted without requiring any manual input. You may think that latex isn't necessary and that manually formatted text will look just as nice -- and you're probably right, in almost all cases manual formatting would look nice enough to do the trick. But there is a fundamental difference between latex and manual formatting, and it's good to have it.
So: Yes, this is worth it.
Regarding various versions of clang-format: There are (of course) also many options you can set, although I just go with the default, which is very good. Yes, there are probably difference between versions (improvements, e.g. for handling template arguments). I'm sure we could settle on a standard version, or a standard set of options.
-erik
On Mon, Jul 6, 2015 at 5:56 PM, Ian Hinder <ian.hinder@aei.mpg.de mailto:ian.hinder@aei.mpg.de> wrote:
On 4 Jul 2015, at 17:06, Erik Schnetter <schnetter@cct.lsu.edu <mailto:schnetter@cct.lsu.edu>> wrote:On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder <ian.hinder@aei.mpg.de <mailto:ian.hinder@aei.mpg.de>> wrote: On 3 Jul 2015, at 23:33, Erik Schnetter <schnetter@cct.lsu.edu <mailto:schnetter@cct.lsu.edu>> wrote:I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding. clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent. I propose to re-format Carpet's source code via clang-format. Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes. Please comment.Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences. I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again. With the above considerations, is it worth doing this? Yes, it definitively is. Not having to worry about indentation and formatting while coding frees the mind; it is a transformative experience.I just press TAB in emacs to make sure the indentation is correct; it's not something I ever really think about. After reading Roland's email, I'm more and more concerned that a large-scale reformatting of an existing codebase with several branches owned by different people is going to cause a fair amount of pain. For a new project, I would definitely use such a system, and when new code is added to an existing project, but I'm not sure it's worth the trouble it will cause for Carpet. -- Ian Hinder http://members.aei.mpg.de/ianhin-- Erik Schnetter <schnetter@cct.lsu.edu mailto:schnetter@cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Yes, clang-format is really good; it's playing in a different league than GNU indent or other prehistoric predecessors. It turns out that clang-format does not chase include statements nor requires knowledge about #define statements, and can thus format each file in isolation. It uses clang's parser, but does not construct the detailed semantic tree structures that clang needs to resolve types. Thus clang-format stays closer to how a human reads code than how a compiler interprets it.
Yes, older versions of clang-format had problems in some special cases. I've encountered issues in hairy template arguments, where clang-format gets confused about the meaning of "<" (template argument or less-than sign?) and "&&" (binary operator or rvalue prefix?). Newer versions of clang-format get this right; otherwise, one can use parentheses to make the meaning clear. Note that these are really dark corners of C++, where it is impossible to tell the difference without knowing whether certain identifiers are types or variables, which depends on details of scoping and namespaces and all previous include files.
Anyway -- we should easily be able to all use the same version of clang-format.
-erik
On Wed, Jul 8, 2015 at 9:39 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
On one hand, clang-format ought to be really good because it can leverage the clang parser and understand the code as well as the compiler. Other tools have to re-engineer the whole process and may not get it exactly right. I'm rarely completely happy with auto-format, and because of that I only ever apply it to small areas of code at a time.
On the other hand, there is a potential version issue. I just formatted a simple code with two versions of clang-format I had installed on my laptop and got different results. The older version messed up the formatting of a C++11 initializer. While the C++11 issues are probably not going to be a problem going forward, other issues might crop up. I could easily imagine bits of formatting changing back and forth as two developers with different versions of clang updated the source.
Cheers, Steve
On 07/07/2015 10:51 AM, Erik Schnetter wrote:
Yeah, that's what I thought in the beginning -- code formatting is all about indentation, which is handled by the tab key. But it turns out, it isn't. I only noticed after using clang-format for some way. Code formatting ties up part of your brain, every time you type a character, you have to ask yourself "do I need to insert a space", "do not need to insert a line break", "should I join these two lines again", "does this comments need re-formatting", "should I line-wrap this lengthy expression differently", "how do I make these lines line up nicely", etc.
With clang-format -- none of this. You type in the content you want, you insert spaces where absolutely necessary, you save, and when you look again, the code looks nice. And you can relax in the knowledge that this formatting is a projection -- there's no "other way" that maybe might look better.
Also, clang-format doesn't indent namespaces the way the tab key does, and it doesn't make errors. Clang-format is the complete separation of form and content, and you only have to care about the latter. Think of it as latex: You type the text, and it will look well-formatted without requiring any manual input. You may think that latex isn't necessary and that manually formatted text will look just as nice -- and you're probably right, in almost all cases manual formatting would look nice enough to do the trick. But there is a fundamental difference between latex and manual formatting, and it's good to have it.
So: Yes, this is worth it.
Regarding various versions of clang-format: There are (of course) also many options you can set, although I just go with the default, which is very good. Yes, there are probably difference between versions (improvements, e.g. for handling template arguments). I'm sure we could settle on a standard version, or a standard set of options.
-erik
On Mon, Jul 6, 2015 at 5:56 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 4 Jul 2015, at 17:06, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 3 Jul 2015, at 23:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.
clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.
I propose to re-format Carpet's source code via clang-format.
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
Please comment.
Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences.
I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again.
With the above considerations, is it worth doing this?
Yes, it definitively is. Not having to worry about indentation and formatting while coding frees the mind; it is a transformative experience.
I just press TAB in emacs to make sure the indentation is correct; it's not something I ever really think about. After reading Roland's email, I'm more and more concerned that a large-scale reformatting of an existing codebase with several branches owned by different people is going to cause a fair amount of pain. For a new project, I would definitely use such a system, and when new code is added to an existing project, but I'm not sure it's worth the trouble it will cause for Carpet.
-- Ian Hinder http://members.aei.mpg.de/ianhin
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
Anyway -- we should easily be able to all use the same version of clang-format.
Easily: Weeellll maybe.
On my workstation using Debian (testing) the only version that I can easily use are: 3.4 and 3.5 . On my OSX laptop Homebrew installs a version that identifies as 3.7 (no other version provided it seems, at least brew search clang-format only finds the one formula). One should be able to compile clang-format from scratch, I have never done so though.
I'd normally suggest to try this (now since it is at the beginning of a release lifetime) and see how well we fare. However I don't know how one would "undo" the use of automatic formatting of the repository during the testing stage if we end up not liking the results.
Yours, Roland
Well, let's start small then. I suggested Carpet since it is smaller than Cactus, or all of the ET. But maybe we should start out even smaller -- maybe with one of the CactusUtils thorns. Let's pick Formaline; this one has a formatting that's different from almost all other thorns anyway, and it doesn't see much development.
-erik
On Wed, Jul 8, 2015 at 6:15 PM, Roland Haas rhaas@aei.mpg.de wrote:
Hello all,
Anyway -- we should easily be able to all use the same version of clang-format.
Easily: Weeellll maybe.
On my workstation using Debian (testing) the only version that I can easily use are: 3.4 and 3.5 . On my OSX laptop Homebrew installs a version that identifies as 3.7 (no other version provided it seems, at least brew search clang-format only finds the one formula). One should be able to compile clang-format from scratch, I have never done so though.
I'd normally suggest to try this (now since it is at the beginning of a release lifetime) and see how well we fare. However I don't know how one would "undo" the use of automatic formatting of the repository during the testing stage if we end up not liking the results.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Erik, all,
Well, let's start small then. I suggested Carpet since it is smaller than Cactus, or all of the ET. But maybe we should start out even smaller -- maybe with one of the CactusUtils thorns. Let's pick Formaline; this one has a formatting that's different from almost all other thorns anyway, and it doesn't see much development.
I just ran clang-format-3.5 on your branch (which used clang-format-3.6 something) and the results agree. So (assuming I check my commits for unexpected changes) I can use Debian's clang-format.
Yours, Roland
Hello all,
I just press TAB in emacs to make sure the indentation is correct; it's not something I ever really think about.
Well, one has to define "correct". In Carpet one should do more than just pick whatever one likes, I believe. Ideally one should read a document with the desired coding style (see eg AHFinderDirect/src/CODESTYLE or http://einsteintoolkit.org/documentation/MaintGuide/MaintGuidech2.html#x4-30...) or at least look around a bit to try and learn what the original author uses (in Carpet's case eg the use of "and" and "or" instead of "&&" and "||", indentation for blocks, whether to use braces for single statements in if/else constructs).
Erik's change basically tries to avoid having to do so manually. Given that our code is somewhat non-standard (due to eg the BEGIN_GLOBAL_MODE type macros and the CCTK_LOOP type macros) we'd need to craft a specific configuration file for clang-format to get nice results I think.
After reading Roland's email, I'm more and more concerned that a large-scale reformatting of an existing codebase with several branches owned by different people is going to cause a fair amount of pain.
I thought about it a bit, I think git's filter-branch command can simplify this:
git filter-branch --tree-filter 'find . -name *.hh -or -name *.cc -print0 | xargs --null clang-format --style llvm -i' BRANCH-NAME
seems to do the trick (though it's slow, runtime on the order of 1.5 hours per branch on my workstation). It is still disruptive to diff though so I like the idea of only applying clang-format to new commits better. Erik's choice though.
Yours, Roland
Hello all,
Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.
I tend to not like reformatting code, since I am just now struggling re-integrating changes into SpEC where the original author realigned code lines to look "nicer". I effectively end up having to re-implement the changes since git merge simply cannot deal with the amount of changes present.
My reasons are basically the ones Ian outlined: using diff between pre and post-format revisions becomes almost impossible. I also suspect that there are instances where a particular indentation is desired to eg align different conditions in a long if statement that clang-format would not capture properly.
Do you have a particular version you would like to use? Debian adds the version number to its clang-format package names which tends to be an indication that the different versions are not drop-in replacements for each other. We'd definitely want to avoid an automated formatting war due to different clang-format versions producing different output.
On the level of things that mostly affect myself: I have many local branches with multiple commits past the branching point. Would you know already how to use clang-format to have all commits in there reformatted so that I can rebase them onto the master (eg to propose a pull request)? Otherwise the option would seem to be to have a "reformat with clang" commit in each branch and do an actual git-merge to bring the branches up to date with master. So far merges have been rare and seemed frowned upon.
If one only wants to have clang-format take care of newly added code, which may be less disruptive and still frees the authors from having to worry about formatting, then one can (hopefully) use this:
https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-for...
which should be executed before "git add".
In the end though, I think that the main author gets to choose the coding style they would like to use (unless the code is in Cactus in which case he Cactus coding style applies). If this is "clang-formatted all the way down" then so be it.
Yours, Roland
Hi
On Fri, Jul 03, 2015 at 05:33:55PM -0400, Erik Schnetter wrote:
I propose to re-format Carpet's source code via clang-format.
One question I couldn't find an easy answer for using Google: how often and how much does the default format style change?
The reason I am asking is that if that happens, not only will we have users with different versions having the problem of back-and-forth only-format changes, we also will have to create a lot of 'update to format x' commits to avoid mixing them with real changes.
The same would happen if we decide that the default isn't doing exactly what we want, and change it. (and I've seen a few examples I didn't like - just not yet some I would care enough about).
Did anyone compare the available styles for C++, and how often _they_ change?
Frank
On Tue, Jul 14, 2015 at 2:18 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi
On Fri, Jul 03, 2015 at 05:33:55PM -0400, Erik Schnetter wrote:
I propose to re-format Carpet's source code via clang-format.
One question I couldn't find an easy answer for using Google: how often and how much does the default format style change?
The reason I am asking is that if that happens, not only will we have users with different versions having the problem of back-and-forth only-format changes, we also will have to create a lot of 'update to format x' commits to avoid mixing them with real changes.
The same would happen if we decide that the default isn't doing exactly what we want, and change it. (and I've seen a few examples I didn't like
- just not yet some I would care enough about).
Did anyone compare the available styles for C++, and how often _they_ change?
clang-format knows different styles (LLVM, Google, Chromium, Mozilla, WebKit), and of course you can define your own via .clang-format files, usually using one of these four as starting point. I briefly looked at them, and I found LLVM to be the closest to "usual" (dense) C++ formatting; LLVM unsurprisingly also the default.
I agree that clang-format makes sometimes choices that I wouldn't make. However, the resulting code is always very readable. And since the whole point of using an automated formatter is that one doesn't have to care about the style and fine-tune it, I decided to simply use the LLVM style and forego the bikeshedding.
I don't think these styles change at all. I'm not aware of changes in the past year. They have seen improvements to certain corner cases, or have been extended to handle C++14 and now C++17 constructs, but I'm not aware of any changes ("hey! let's change indentation from 2 to three 3 spaces!").
-erik
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Roland Haas -
Steven R. Brandt