https://bugzilla.redhat.com/show_bug.cgi?id=1564149
--- Comment #11 from Jeff Darcy <j...@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. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zW0VzdcJDh&a=cc_unsubscribe _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra