[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jan 2018 22:41:23 -0600
From: Samuel Holland <samuel@...lland.org>
To: musl@...ts.openwall.com, Jens Gustedt <jens.gustedt@...ia.fr>
Subject: Re: automated coding style
Hello,
On 01/03/18 08:08, Jens Gustedt wrote:
> On Thu, 21 Dec 2017 18:34:02 -0500 Rich Felker <dalias@...c.org> wrote:
>> On Thu, Dec 21, 2017 at 12:06:55PM +0100, Jens Gustedt wrote:
>>>> There seems to be some mixing of tabs and spaces here and in a few
>>>> other lines. Tabs should be used for indentation levels, spaces (after
>>>> any initial indent) to column-align. Generally musl style also has
>>>> continuation comment lines begin with a * aligned with the * of the
>>>> opening /* too.
>>>
>>> Since I ran into similar comments before and I find it quite frustrating
>>> and disruptive:
>>
>> By similar comments do you mean existing comments in the musl source
>> styled like you did it, or similar email comments before about styling
>> matters?
>
> comments about style.
>
> it think an automatic formatting procedure that accommodates everybody could
> help us focus on contents
>
>> I'm not familiar with these tools, so I could look into it, but someone
>> else interested might be able to get to it before me. I'll see. The way I
>> deal with touching code in lots of different projects with different
>> styles is having my editor configured to copy exactly the leading
>> whitespace of the previous line when adding a new line, and then adding or
>> deleting tabs or spaces as appropriate. But I can see how that's not
>> agreeable to everyone.
>>
>> Actually now that I think about it, I'm pretty sure the official Linux
>> kernel style is nearly the same as preferred style in musl, and should
>> usually produce formatting that's perfectly acceptable.
>
> so for my latest patches I experimented with
>
> astyle --style=linux --indent=tab
>
> This helps a lot, already. Unfortunately, this combination still changes
> some musl sources, basically because indentation of continuation lines is
> handled differently.
I'm familiar with three source code formatting tools for C: astyle,
clang-format, and uncrustify. I haven't used astyle, because it seems to be the
least flexible of the three.
clang-format is very stable and consistent, and has a moderate number of
configuration options. However, because it is designed for use with C++, it has
poor handling of C braced initializers, especially designated initializers. It
also is unable to align macro definitions, making it unusable on musl's headers.
The changeset for this feature has been open for over a year and doesn't look
like it will be merged soon: https://reviews.llvm.org/D28462
uncrustify is the most flexible of the three, making it the best for matching an
existing code style. It's also a bit buggier than clang-format, especially when
the tool wraps long lines for you (though this doesn't affect code already
following a line length limit).
I wrote a script to permute over 600 of the options to uncrustify and generate a
configuration with the smallest diff from the current musl source. Attached is
that configuration file, as well as a diffstat from 628cf979b249. You can see
most of the changes are in the inline assembly syntax, continuation of header
namespace guards, and the imported code in src/math and src/regex.
I don't claim that this file represents the "official musl style", especially
because it's autogenerated, but hopefully it's useful for formatting patches.
Regards,
Samuel
View attachment "uncrustify" of type "text/plain" (15471 bytes)
View attachment "diffstat" of type "text/plain" (18373 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
