[Bugs] [Bug 1564149] Agree upon a coding standard, and automate check for this in smoke

bugzilla at redhat.com bugzilla at redhat.com
Tue Apr 17 16:25:23 UTC 2018


https://bugzilla.redhat.com/show_bug.cgi?id=1564149



--- Comment #11 from Jeff Darcy <jeff at pl.atyp.us> ---
Whatever we pick is going to require some tweaking. Some of the things I
notice:

 * All use two-space indents, which I personally find atrocious.

 * All put a function's type on the same line as its name.

 * All put the opening brace for a function on the last line of the arguments,
instead of at the beginning of a separate line.

 * Mozilla, Webkit, and LLVM indent 'case' from 'switch'

 * None enforce a space between a function name and opening paren in calls.

 * Mozilla, LLVM, and Google all express pointers as "type* name" instead of
the more familiar (in our code) "type *name"

So Chromium seems closest, but none are particularly close. Looking at the
clang-format pages, here are some options I'd suggest for compatibility with
our existing standard:

 !AllowShortIfStatementsOnASingleLine
 !AllowShortLoopsOnASingleLine
 BraceWrapping(!AfterControlStatement)
 BraceWrapping(AfterFunction)
 BraceWrapping(!BeforeElse)
 ColumnLimit(80)
 !IndentCaseLabels
 IndentWidth(8) or IndentWidth(4) depending on outcome of that conversation
 PointerAlignment(PAS_Right)
 SpaceBeforeParens(SBPO_Always)
 TabWidth(8)
 UseTab(UT_Never)

This fixes most of the warts, though I don't see an option to control function
type and name on the same line and I didn't expect one to enforce braces around
single statements (which would be nice).

BTW, yes, I know that our coding style is rather archaic. The fact that all of
Clang's defined styles are so different than ours is testament to that. There
are some who would argue that any "big bang" reformatting should modernize as
many aspects as possible, including even function opening braces and
(*shudder*) two-wide indents. I'm not necessarily opposed to such changes, but
I think they need to be considered *individually* and not just adopted by
accident. We already did that once, when we imported a check script from the
Linux kernel without anything resembling proper review and it turned out to be
wildly incompatible with our existing code. Let's not repeat that mistake.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list