Thread (18 messages) flat view 18 messages, 6 authors, 11d ago

RE: Automatic code formatting

From: <hidden>
Date: 2022-07-10 22:13:18

On July 10, 2022 5:50 PM, brian m. carlson wrote:
In the past, we've discussed the possibility of using an automatic code formatter
for Git.  That discussion has, as we've seen, not led to us using one.  I'd like to
reopen the discussion and provide a couple reasons why I think it's a good idea.

We've spent a lot of work encouraging newcomers to contribute to Git.
It's demoralizing when your code comes back with many code style nits to fix, and
it leads to a barrier to contribution.  I also find that I am likely to take longer to
reroll a series if there are many nits to be fixed, and I find that code style
comments are a frequent discussion topic on my series (even though I generally
try to be cognizant of them).

Having a code formatting tool means that the work for a contributor to format the
file properly consists of about two keystrokes.  This substantially reduces the
amount of time that contributors must spend thinking about code formatting and
simplifies it to an automatic process that, if we choose, can even be verified in CI.

Most projects written in languages like Rust or Go use an automatic formatter.  In
Go's case, the formatter is specifically stated to be a fixed style that is nobody's
favourite, but because there's an automatic formatter, everybody just uses it.
Personally, I don't love our coding style now (I'm a 4-space person in C), but I
would love it a lot more if I didn't have to think about it.  I am substantially less
picky about what the style is than that we have an automated tool to tidy our
code, and I'm okay with us producing the occasional slightly suboptimal style for
the improved efficiency we get.

The impetus for me bringing this up is that I'm rebasing the
SHA-1/SHA-256 interop work to continue work on it and I find myself spending a
lot of time cleaning up formatting that I could instead be spending on debugging
why my tests are failing or writing new code.  I would like to spend less time on
boring scut work and more time solving interesting problems, as I'm sure we all
would.

I should point out that most platforms (and all major platforms) have clang and
therefore I think clang-format should be a fine choice.  It's highly configurable and
will let us pick a style that most resembles the one we have now. However, I'm
not picky and if we like something else better, great.  As long as the option we pick
is shipped in Debian, I'm for it.

I should note that we already have a .clang-format file, so we can already use
clang-format.  However, we cannot blindly apply it because it produces output
that is not always conformant with our style.  My proposal here is to define our
style in terms of the formatter to avoid this problem.

Hopefully we can move forward with this discussion and come to some productive
resolution.
Being one of the platforms that will be specifically excluded from this proposal, I would like to offer an alternative. Before that, please remember that not everything is Linux. My suggestion is to create infrastructure to automatically format on add/commit. This could be pluggable relatively simply with clean filter that is language specific - perhaps with a helper option that installs the formatter easily (because clean filters are notoriously painful to install for newbies from my observations). It would be nice to have something in perl that is more portable and pervasive than clang - although perl could launch clang where available. I think having infrastructure for code formatting that is built into git is actually highly desirable - assuming that it is not unduly difficult to install those. It would extend beyond git contributions, but the contributors could be told (Contributor's Guide) that then need to follow standard X, which may very well be clang format. There are java formatters, php and perl formatters, even COBOL and TAL formatters. My position is that having a standard way to plug these in is a more general plan that would reach a larger community. Git contributions could then just leverage standard git functionality.

--Randall
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help