Re: automated formatting

[Han-Wen Nienhuys]

On Mon, Jan 27, 2020 at 11:49 AM David Kastrup <address@hidden> wrote:
> > I want to propose to move to automated formatting for our C++ code.
> >
> > I put up a .clang-format code that mostly mimicks our style at
> >
> >   https://codereview.appspot.com/561340043
> >
> > I have a lot of good experience with automating code formatting.. It
> > removes drudgery for code authors, obviates discussions over style in
> > code review, and generally elevates the level of discourse in our
> > reviews.
> >
> > What do you all think?
>
> scripts/auxiliar/fixcc.py and astyle 2.04 is what we standardized on.

Yes, I am proposing that we change and standardize on clang-format.

> > The current config modifies about 11k lines, mostly because of
> > different line breaks (necessary to keep the 80 column limit.)
>
> Any particular reason to change the automated style to a different one?

Several reasons

* clang-format is a *complete* formatter. It reformats files to a
canonical formatting regardless of how badly you mangle the input.

For example, if you introduce a comment line of 200 chars. In
clang-format, this will be reformatted to the specified column limit.
Astyle/fixcc doesn't know what to do with it.

* clang-format is based on clang itself, and has an understanding of
the source code being formatted. This makes it better than fixcc which
uses regular expressions (sic) to make sense of C++. This is
especially important as we move towards newer dialects of  C++ with
newer constructs (eg. lambda).

* Because it is so robust, it is safe to run automatically on save,
and there exists VIM and Emacs support to do so

* fixcc is 500 lines of python that we could just stop maintaining.

* clang-format is fast. I can format all of the LilyPond C++ code in 4
seconds. That makes it fast enough to stick into a pre-commit hook
(check changed files for formatting).

* clang-format is configurable. I whipped a config that I think
matches what we have, but I might have missed some options. Ideally,
the changes would be small.

* clang-format is well-established. Both the linux kernel and Git have
a .clang-format files in their trees.

Finally, commenting on Werner: there are two main positives for
automated formatting:

1. you can stop caring about formatting complely, ie.

> The 80 column limit is a special beast.  Sometimes it *does* make
> sense to not follow this restriction, especially if the excess is just
> a few characters...

when the formatting is completely automatic, there is "follow" or "not
follow". You simply press "Save" and the code is formatted as it is
supposed to be. Maybe that means the result is slightly suboptimal in
specific situations, but overall, not having to think about formatting
is very liberating.

2. When code has standard formatting, it is much easier to build
automation for code changes, or do global search/replaces over the
code base. (This is probably not a big factor for LilyPond, but it's
what makes large scale automated refactoring feasible at places like
Google.)

> Clang is a pretty big dependency for developers.

You'd think that, but it's not that bad:

$ rpm -qi clang| grep Size
Size        : 1695283

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen