Dear all, First of all, I like Martin's initiative as any attempt at trying to improve the situation is very welcome. Hartmut is of course right that it should be discussed, but I think committing the files first so we have a good basis for discussion was also the right move. It's not like Martin reindented the entire project already ;-). So please no drama on this, there is really not even a conflict.
I have a few options that -- based on reading only the documentation and
not yet trying it out on actual code -- I would set differently (diff
attached for discussion).
I worry a bit that applying an auto-formatter will inherently destroy
particularly neat formatting, i.e.
fun (key, value,
key2, value2,
key3, value3)
is likely going to end up with
fun (key,
value,
key2,
value2);
as there is simply no way of teaching such exceptions to the
auto-formatter. OTOH, having this done in a consistent way will also
avoid a lot of stupid reindentation commit work, so the trade-off might
be worth it.
Now, *if* this actually works acceptably (I have not tested it), we
would want to have it in the emacs configuration, but also as a local
hook for Git (auto-format before commit?), plus as a hard check on the
server (is it indented? no? go away!).
Anyway, that's not today, for now I would just encourage everyone to
play with Martin's suggestion, propose adjustments to the style (see my
attached diff) and report code that ends up formatted "badly" here to
see if we 'dare' to automate and enforce this.
Happy hacking!
Christian
On 4/15/19 11:35 AM, Florian Dold wrote:
> Hi Hartmut,
>
> It's a bit disheartening to see an honest attempt to improve things
> being shot down like this.
>
> The clang-format style that Martin created tries to mirror what style
> the existing codebase already has or is supposed to have. If you want
> to make any tweaks on top of that, please contribute them or voice your
> criticism constructively!
>
> GNUnet isn't completely following the GNU Coding Standards anyway, is it?
>
> And to suggest that everybody should use Emacs to format code is
> outright ridiculous. Unlike clang-format, it does not integrate into
> other editors (yes, those do exist!), and it sucks badly at formatting
> code. It only does indentation. Well, unless your lines are too long.
>
> GNUnet is rife with "char * foo;", weirdly formatted macros and overly
> long lines. Emacs won't fix those.
>
> Please also think of people (students!) that don't have your exact setup
> and want to contribute to GNUnet without having to use Emacs, and
> without somebody having to do manual code review for code style. At
> least Guix has some helper script that formats the code using Emacs
> under the hood, without having to know Emacs!
>
> - Florian
>
> On 4/15/19 10:53 AM, Hartmut Goebel wrote:
>> Am 15.04.19 um 10:02 schrieb Schanzenbach, Martin:
>>> FYI I added a clang-format at "contrib/conf/editors/clang-format".
>>
>> I'm curious about this, since the development guide says: "We follow the
>> GNU Coding Standards (see The GNU Coding Standards
>> <https://www.gnu.org/prep/standards/standards.html#Top> in The GNU
>> Coding Standards).
>>
>> Beside this: If you switch to clang coding style, please adjust
>> .dir-locals.el to pull in the correct settings and make sure this is
>> available in all of our repos. See
>> https://lists.gnu.org/archive/html/gnunet-developers/2019-03/msg00055.html
>>
>> Also I'm curious about you adding this to the code first and then
>> discussion the topic. If we decide *not* to change the coding style, we
>> will have dead artifacts trashing all developers repos for years.
>>
>
> _______________________________________________
> GNUnet-developers mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>
diff --git a/contrib/conf/editors/clang-format b/contrib/conf/editors/clang-format index 97493b58a..992b2e6e1 100644 --- a/contrib/conf/editors/clang-format +++ b/contrib/conf/editors/clang-format @@ -5,21 +5,21 @@ AccessModifierOffset: -2 AlignAfterOpenBracket: Align AlignConsecutiveAssignments: false AlignConsecutiveDeclarations: false -AlignEscapedNewlines: Right -AlignOperands: true -AlignTrailingComments: true -AllowAllParametersOfDeclarationOnNextLine: true +AlignEscapedNewlines: Left +AlignOperands: true # CG: not precisely what I like, but OK +AlignTrailingComments: false +AllowAllParametersOfDeclarationOnNextLine: false # CG: documentation has AllowAllArgumentsOfDeclarationsOnNextLine! AllowShortBlocksOnASingleLine: false AllowShortCaseLabelsOnASingleLine: false AllowShortFunctionsOnASingleLine: All AllowShortIfStatementsOnASingleLine: false AllowShortLoopsOnASingleLine: false -AlwaysBreakAfterDefinitionReturnType: None +AlwaysBreakAfterDefinitionReturnType: All AlwaysBreakAfterReturnType: TopLevel AlwaysBreakBeforeMultilineStrings: false AlwaysBreakTemplateDeclarations: MultiLine -BinPackArguments: true -BinPackParameters: true +BinPackArguments: false # FIXME: ideally exceptions apply for key-value pairs +BinPackParameters: false BraceWrapping: AfterClass: false AfterControlStatement: false @@ -36,7 +36,7 @@ BraceWrapping: SplitEmptyFunction: true SplitEmptyRecord: true SplitEmptyNamespace: true -BreakBeforeBinaryOperators: None +BreakBeforeBinaryOperators: All BreakBeforeBraces: Custom BreakBeforeInheritanceComma: false BreakInheritanceList: BeforeColon @@ -44,7 +44,7 @@ BreakBeforeTernaryOperators: true BreakConstructorInitializersBeforeComma: false BreakConstructorInitializers: BeforeColon BreakAfterJavaFieldAnnotations: false -BreakStringLiterals: true +BreakStringLiterals: false ColumnLimit: 80 CommentPragmas: '^ IWYU pragma:' CompactNamespaces: false @@ -94,9 +94,10 @@ PenaltyExcessCharacter: 1000000 PenaltyReturnTypeOnItsOwnLine: 60 PointerAlignment: Right ReflowComments: true -SortIncludes: true +SortIncludes: false SortUsingDeclarations: true SpaceAfterCStyleCast: false +SpaceAfterLogicalNot: true SpaceAfterTemplateKeyword: true SpaceBeforeAssignmentOperators: true SpaceBeforeCpp11BracedList: false
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
