[Development] clang-format

André Pönitz apoenitz at t-online.de
Tue Jun 19 23:23:10 CEST 2018


On Wed, Jun 20, 2018 at 06:30:26AM +0000, Lars Knoll wrote:
> 
> 
> > On 19 Jun 2018, at 18:19, Ville Voutilainen
> > <ville.voutilainen at gmail.com> wrote:
> > 
> > On 19 June 2018 at 19:13, Philippe <philwave at gmail.com> wrote:
> >>> For the above reasons I'd lean towards not running it globally and
> >>> just using it on new changes.
> >> 
> >> +1, based on my clang-format experience on a big application.
> >> 
> >> BTW, keep in mind that you can disable clang-format on code
> >> sections with:
> >> 
> >> // clang-format off // clang-format on
> > 
> > When I last experienced a large-scale clang-format reformat, it
> > really hurt development during the churn. We should somehow manage
> > to do it during a time when there aren't many pending patches in the
> > pipeline. I'm not concerned about git-blame; that has never been a
> > problem after reformats. However, I do not care about indentation
> > nor do I want to spend time on it either way, it has no actual
> > effect on readability and maintainability of code, and consistency
> > outside the file you're in has never mattered to me one bit.
> > 
> > IOW, I'm not opposed to reformats and auto-checking of clang-format
> > (or even hooking it), but I do not see it as a thing with all that
> > great return-of-investment.
> 
> It helps in that you do not need to point those things out in code
> reviews, and that I (and others) won’t even create changes with wrong
> formatting that I’ll need to fix up later on. It’s part of a larger
> story, where I would like to get as much automatic checking of changes
> done before humans start reviewing.

It's also a cultural thing.

Quite a few people seem to take less offense from a "Your formatting is
bad" when the comment comes from a bot than when it comes from a human. 

> One idea could be to introduce this incrementally. Let’s first start
> off with enforcing it for new changes. Then we run it globally over
> the code base shortly before Qt 6.0 is being released. At that time
> merges shouldn’t be as much of a problem (as we’ll probably
> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will
> be properly formatted (due to the earlier hook).

Incrementally sounds good to me.

Still I am a bit of a fence here. So far I've seen a couple of auto-
formatting attempts biting back, so I thinl it would help to convince me
to see the kind of changes that would happen first before deciding
on the global change.

Andre'



More information about the Development mailing list