[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Coding style clang-format
From: |
Schanzenbach, Martin |
Subject: |
Re: [GNUnet-developers] Coding style clang-format |
Date: |
Mon, 15 Apr 2019 18:58:37 +0200 |
> On 15. Apr 2019, at 12:24, Christian Grothoff <address@hidden> wrote:
>
> Signed PGP part
> 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.
I don't think clang-format can do that as this semantic is not generalizable.
But, I also think this is not something an editor config can achieve so we
could just disable auto indent of function parameters in the clang-format.
>
> 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!).
clang-format is a CLI tool. So I assume this is trivial.
>
> 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.
Yep! If sb does not want to use it _in_ the editor, the clang-format tool can
still be used in a "make check-syntax" or even better a git hook as you propose.
>
> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>>
> <delta.diff>
>
>
signature.asc
Description: Message signed with OpenPGP
- [GNUnet-developers] Coding style clang-format, Schanzenbach, Martin, 2019/04/15
- Re: [GNUnet-developers] Coding style clang-format, Hartmut Goebel, 2019/04/15
- Re: [GNUnet-developers] Coding style clang-format, Florian Dold, 2019/04/15
- Re: [GNUnet-developers] Coding style clang-format, Schanzenbach, Martin, 2019/04/16
- Re: [GNUnet-developers] Coding style clang-format, Christian Grothoff, 2019/04/16
- Re: [GNUnet-developers] Coding style clang-format, Schanzenbach, Martin, 2019/04/16
- Re: [GNUnet-developers] Coding style clang-format, Schanzenbach, Martin, 2019/04/16
- Re: [GNUnet-developers] [Update] Coding style clang-format, Schanzenbach, Martin, 2019/04/17
Re: [GNUnet-developers] Coding style clang-format, Schanzenbach, Martin, 2019/04/15