> 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 <[email protected]> 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 <[email protected]> On > Behalf Of Thiago Macieira > Sent: Friday, June 22, 2018 08:26 > To: [email protected] > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
