[Development] clang-format

[Scott Bloom]

I cant even get my developers to agree the emacs takes to many fingers, and VI(m) is the only editor they need....

Let alone, where the brackets and spaces belong....

Let alone, if statements on the same line as the conditional....

The problem ive seen, is while you may LOVE the curly brackts on the same line, you will never convince me... 😊




-----Original Message-----
From: Development <development-bounces+scott=towel42.com at qt-project.org> On Behalf Of Philippe
Sent: Friday, June 22, 2018 09:12
To: development at qt-project.org
Subject: Re: [Development] clang-format

>  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


_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development