| Message ID | 29b489fe-d7ad-68b8-b555-2a6381a28829@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ./CODING_STYLE adjustments | expand |
Hi Jan, Jan Beulich writes: > For easy spotting of struct/union/enum definitions we already commonly > place the opening braces on the initial line of such a definition. > > We also often don't place the opening brace of an initializer on a > separate line. > > And finally for compound literals placing the braces on separate lines > often makes the code more difficult to read, so it should (and in > practice does) typically go on the same line as well. The placement of > the closing brace often depends on how large such a compound literal is. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > TBD: We may want to make explicit that for initializers both forms are > fine. > > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -64,8 +64,13 @@ Bracing > ------- > > Braces ('{' and '}') are usually placed on a line of their own, except > -for the do/while loop. This is unlike the Linux coding style and > -unlike K&R. do/while loops are an exception. e.g.: > +for > +- the do/while loop > +- the opening brace in definitions of enum, struct, and union > +- the opening brace in initializers > +- compound literals Looks like this leaves us only with "if/else", "for", "switch" and various forms of "for_each_*". So maybe it is worth to rewrite this in the opposite manner? Like this: Braces ('{' and '}') are usually placed on the same line, except the following cases: - if, else, for, switch statements - for_each_* iterators like for_each_vcpu > +This is unlike the Linux coding style and unlike K&R. do/while loops There is extra space before "do/while". > +are one exception. e.g.: > > if ( condition ) > { > -- Volodymyr Babchuk at EPAM
On 19.07.2019 18:48, Volodymyr Babchuk wrote: > Jan Beulich writes: >> --- a/CODING_STYLE >> +++ b/CODING_STYLE >> @@ -64,8 +64,13 @@ Bracing >> ------- >> >> Braces ('{' and '}') are usually placed on a line of their own, except >> -for the do/while loop. This is unlike the Linux coding style and >> -unlike K&R. do/while loops are an exception. e.g.: >> +for >> +- the do/while loop >> +- the opening brace in definitions of enum, struct, and union >> +- the opening brace in initializers >> +- compound literals > Looks like this leaves us only with "if/else", "for", "switch" and > various forms of "for_each_*". So maybe it is worth to rewrite this > in the opposite manner? Like this: That's an option, but I'm not sure I'd want to go that route. Note also how you don't mention e.g. "asm" and "return". > Braces ('{' and '}') are usually placed on the same line, except the > following cases: > > - if, else, for, switch statements > - for_each_* iterators like for_each_vcpu For the latter I think we want to stick to not mandating style either way: There's already a fair amount of either of the two legitimate forms. It's really a matter of personal taste whether to consider these pseudo-keywords. >> +This is unlike the Linux coding style and unlike K&R. do/while loops > There is extra space before "do/while". No. In such documents it is quite common to have double blanks after a full stop. See e.g. the original text, which had two instances of this. Jan
On Fri, 19 Jul 2019, Jan Beulich wrote: > For easy spotting of struct/union/enum definitions we already commonly > place the opening braces on the initial line of such a definition. > > We also often don't place the opening brace of an initializer on a > separate line. > > And finally for compound literals placing the braces on separate lines > often makes the code more difficult to read, so it should (and in > practice does) typically go on the same line as well. The placement of > the closing brace often depends on how large such a compound literal is. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> > --- > TBD: We may want to make explicit that for initializers both forms are > fine. > > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -64,8 +64,13 @@ Bracing > ------- > > Braces ('{' and '}') are usually placed on a line of their own, except > -for the do/while loop. This is unlike the Linux coding style and > -unlike K&R. do/while loops are an exception. e.g.: > +for > +- the do/while loop > +- the opening brace in definitions of enum, struct, and union > +- the opening brace in initializers > +- compound literals > +This is unlike the Linux coding style and unlike K&R. do/while loops > +are one exception. e.g.: > > if ( condition ) > { > >
--- a/CODING_STYLE +++ b/CODING_STYLE @@ -64,8 +64,13 @@ Bracing ------- Braces ('{' and '}') are usually placed on a line of their own, except -for the do/while loop. This is unlike the Linux coding style and -unlike K&R. do/while loops are an exception. e.g.: +for +- the do/while loop +- the opening brace in definitions of enum, struct, and union +- the opening brace in initializers +- compound literals +This is unlike the Linux coding style and unlike K&R. do/while loops +are one exception. e.g.: if ( condition ) {
For easy spotting of struct/union/enum definitions we already commonly place the opening braces on the initial line of such a definition. We also often don't place the opening brace of an initializer on a separate line. And finally for compound literals placing the braces on separate lines often makes the code more difficult to read, so it should (and in practice does) typically go on the same line as well. The placement of the closing brace often depends on how large such a compound literal is. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- TBD: We may want to make explicit that for initializers both forms are fine.