2:42 p.m.
On Thu, Sep 12, 2019 at 12:18 PM Joe Perches <joe(a)perches.com> wrote:
I don't think that's close to true yet for clang-format.
I don't expect clang-format to match perfectly our current code style.
However, if core maintainers agree that it is "close enough now"
(specially with newer LLVMs, like 9), then there is a great benefit on
moving to automatically-styled code. The "con" is having to change a
bit our style wherever clang-format does not support exactly our
current style.
For instance: clang-format does not do anything with
missing braces, or coalescing multi-part strings,
or any number of other nominal coding style defects
like all the for_each macros, aligning or not aligning
columnar contents appropriately, etc...
Some of these may or may not be fixable tweaking the options. Note
that there are conflicting styles within the kernel at the moment,
e.g. how to indent arguments to function calls. Therefore, some of the
differences do not apply as soon as we decide on a given style.
Furthermore, with automatic formatting we have also the chance to
review some options that we couldn't easily change before.
clang-format as yet has no taste.
I believe it'll take a lot of work to improve it to a point
where its formatting is acceptable and appropriate.
An AI rather than a table based system like clang-format is
more likely to be a real solution, but training that AI
isn't a thing that I want to do.
I don't think we need taste (or AI-like solutions), because
consistency has a lot of value too. Not just for our brains, but for
patches as well.
Note that clang-format is a tool used by major projects successfully,
it is not like we are experimenting too much here :-)
Cheers,
Miguel