[Users] Reformatting Carpet's source code
Steven R. Brandt
sbrandt at cct.lsu.edu
Wed Jul 8 08:39:01 CDT 2015
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 at aei.mpg.de
> <mailto:ian.hinder at aei.mpg.de>> wrote:
>
>
> On 4 Jul 2015, at 17:06, Erik Schnetter <schnetter at cct.lsu.edu
> <mailto:schnetter at cct.lsu.edu>> wrote:
>
>> On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder
>> <ian.hinder at aei.mpg.de <mailto:ian.hinder at aei.mpg.de>> wrote:
>>
>>
>> On 3 Jul 2015, at 23:33, Erik Schnetter
>> <schnetter at cct.lsu.edu <mailto:schnetter at 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 at cct.lsu.edu <mailto:schnetter at cct.lsu.edu>>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150708/49e2650c/attachment-0001.html
More information about the Users
mailing list