[Development] clang-format

[Philippe]

>  I usually come to the conclusion, code in the style you want,
> unless it's a bad format. 

"bad format" is subjective and the use of clang-format precisely
bypasses subjectivity.

> But IMO, wholesale "format changes" have zero value to the customer, so any
> pain associated with them, should be weighed against the time and
> effort necessary to implement a format change that is being taken away from
> customer oriented development.

I have a different POV: everything that eases the developer's work,
means spared development time, hence more productivity, hence benefits to
customers at the end.

Not having to take care of code-formatting, thanks to clang-format, eases
programming.

And looking at someone else code with a familiar format, gives the
feeling "I am home" (provided some naming guideline is respected).

Philippe

On Fri, 22 Jun 2018 15:34:09 +0000
Scott Bloom <scott at towel42.com> wrote:

> Fair enough.. It just seems that this thread has fundamentally become a religious issue over format, and when it should be forced on people...
> 
> I fight this all the time in my organization... I usually come to the conclusion, code in the style you want, unless it's a bad format.  And like pornography, I cant define it but I know it when I see it...
> 
> But IMO, wholesale "format changes" have zero value to the customer, so any pain associated with them, should be weighed against the time and effort necessary to implement a format change that is being taken away from customer oriented development.
> 
> Scott
> 
> -----Original Message-----
> From: Development <development-bounces+scott=towel42.com at qt-project.org> On Behalf Of Thiago Macieira
> Sent: Friday, June 22, 2018 08:26
> To: development at qt-project.org
> Subject: Re: [Development] clang-format
> 
> On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote:
> > In a series of wrapper scripts, essentially, everything checked in was 
> > converted to the check in format.  However each developer had their 
> > own format .  And on checkout, the code would be compare to it.
> > 
> > On "Diff" analysis of two reversions, you had to see the diff based on 
> > the checked in format.
> > 
> > It really made things, that much simpler... and we never heard people 
> > bitch and moan about where the curley brackets belong
> 
> Git has such a functionality, it's called the clean/smudge filters. See man gitattributes for more information.
> 
> But that still means the code you see is subject to the smudge filter's whims. 
> We've concluded that it doesn't always do the right thing.
> 
> And besides, there's something new that didn't exist in the old days: code reviews. Gerrit has no such functionality and in any case, reviewers need to agree between themselves on what they ar reviewing.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development