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 <[email protected]> > --- > 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 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
