|
|
DescriptionAdd a tentative .clang-format for LilyPond.
To try it out, run
clang-format -i lily/include/*[ch] lily/*.cc
Patch Set 1 #Patch Set 2 : just the overrides #Patch Set 3 : reflow #MessagesTotal messages: 17
For which clang-format version is this format file? It doesn't work with 7.0.1, for example. Please add this information to the file.
Sign in to reply to this message.
On 2020/01/27 10:07:20, lemzwerg wrote: > For which clang-format version is this format file? It doesn't work with 7.0.1, > for example. Please add this information to the file. $ clang-format --version clang-format version 9.0.0 (Fedora 9.0.0-1.fc31) can you pinpoint which statements cause problems? We could leave out the default values for enhanced compatibility.
Sign in to reply to this message.
just the overrides
Sign in to reply to this message.
> just the overrides The new version works just fine. Shall I still inspect the previous version for problematic statements? The output looks good. BTW, for the sake of Emacs, it would be nice if two spaces after a full dot could be retained in comments. Does such an option exist?
Sign in to reply to this message.
On 2020/01/29 07:41:40, lemzwerg wrote: > The output looks good. BTW, for the sake of Emacs, it would be nice if two > spaces after a full dot could be retained in comments. Does such an option > exist? Retaining everything with ReflowComments:false might be the only way. https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html
Sign in to reply to this message.
reflow
Sign in to reply to this message.
On 2020/01/29 12:19:54, Dan Eble wrote: > On 2020/01/29 07:41:40, lemzwerg wrote: > > The output looks good. BTW, for the sake of Emacs, it would be nice if two > > spaces after a full dot could be retained in comments. Does such an option > > exist? > > Retaining everything with ReflowComments:false might be the only way. > https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html I've applied your suggestion; PTAL.
Sign in to reply to this message.
On 2020/01/31 09:39:33, hanwenn wrote: > I've applied your suggestion; PTAL. If Werner likes it, I'm fine with it. I haven't tried it myself because I want to avoid being drawn into discussing the details of the style, but I like seeing movement toward a better process.
Sign in to reply to this message.
On 2020/01/31 12:35:45, Dan Eble wrote: > On 2020/01/31 09:39:33, hanwenn wrote: > > I've applied your suggestion; PTAL. > > If Werner likes it, I'm fine with it. I haven't tried it myself because I want > to avoid being drawn into discussing the details of the style, but I like seeing > movement toward a better process. that's great to hear. Will james pick this up automatically now, or does it need an LGTM?
Sign in to reply to this message.
IIUC, this is a .clang-format that can be (but is not required to be) used to format source code and prevent comments about formatting. At this point, we are not enforcing a shift to clang-format as the code standard for LilyPond. If this is true, LGTM. If we are enforcing a shift to clang-format, then I think we need an LGTM from David K.
Sign in to reply to this message.
On 2020/01/31 18:33:38, Carl wrote: > IIUC, this is a .clang-format that can be (but is not required to be) used to > format source code and prevent comments about formatting. > > At this point, we are not enforcing a shift to clang-format as the code standard > for LilyPond. > > If this is true, LGTM. > > If we are enforcing a shift to clang-format, then I think we need an LGTM from > David K. correct.
Sign in to reply to this message.
On 2020/01/31 18:06:00, hanwenn wrote: > Will james pick this up automatically now, or does it need > an LGTM? James should pick it up automatically now.
Sign in to reply to this message.
> If Werner likes it, I'm fine with it. I do like it, and it is completely non-intrusive since it gets used locally only for those people who set up a proper git hook (or call `clang-format` manually).
Sign in to reply to this message.
I'm running some of my patches through clang-format as I prepare to push them. This is an example of a kind of change it wants to make: - const array<int, 2> key {column_rank, dir}; + const array<int, 2> key{column_rank, dir}; Note the space after key. The setting that controls this is SpaceBeforeCpp11BracedList. Am I correct that we should use a space here for consistency with historical style? More examples of the effect of the option are in the docs: https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html
Sign in to reply to this message.
On 2020/02/04 20:35:40, Dan Eble wrote: > I'm running some of my patches through clang-format as I prepare to push them. > > This is an example of a kind of change it wants to make: > > - const array<int, 2> key {column_rank, dir}; > + const array<int, 2> key{column_rank, dir}; > > Note the space after key. The setting that controls this is > SpaceBeforeCpp11BracedList. Am I correct that we should use a space here for > consistency with historical style? > > More examples of the effect of the option are in the docs: > https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html historically, we didn't have C++11, so this wasn't an issue. I'm fine with whatever you pick. With the space seems more coherent with the s p a c e y GNU style.
Sign in to reply to this message.
On 2020/02/04 22:18:23, hanwenn wrote: > On 2020/02/04 20:35:40, Dan Eble wrote: > > I'm running some of my patches through clang-format as I prepare to push them. > > > > This is an example of a kind of change it wants to make: > > > > - const array<int, 2> key {column_rank, dir}; > > + const array<int, 2> key{column_rank, dir}; > > > > Note the space after key. The setting that controls this is > > SpaceBeforeCpp11BracedList. Am I correct that we should use a space here for > > consistency with historical style? > > > > More examples of the effect of the option are in the docs: > > https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html > > historically, we didn't have C++11, so this wasn't an issue. I'm fine with > whatever you pick. > > With the space seems more coherent with the s p a c e y GNU style. Personally, the best of two worlds would be if a ping-pong between our current Astyle and clang-format would end up stable after one application of each. That way, putting the code base through both Astyle and clang-format semi-regularly would put it into a form where users of either formatting tool could contribute their changes without affecting already formatted code in the same file.
Sign in to reply to this message.
On 2020/02/04 23:40:03, dak wrote: > Personally, the best of two worlds would be if a ping-pong between our current > Astyle and clang-format would end up stable after one application of each. That > way, putting the code base through both Astyle and clang-format semi-regularly > would put it into a form where users of either formatting tool could contribute > their changes without affecting already formatted code in the same file. +1. I actually tried that earlier today, and there were lots of differences. I was using astyle 3.1 because that's what I had, so I'm not sure it represents the ideal, but I'm confident that this clang-format file needs some work regardless. It's a good start, though.
Sign in to reply to this message.
|