Re: [Development] clang-format
> It doesn't help me all that much to have > familiar formatting and naming in a translation > unit This is a good skill. But the idea is to help developers that don't have this skill. Philippe On Fri, 22 Jun 2018 19:47:14 +0300 Ville Voutilainen wrote: > On 22 June 2018 at 19:39, Scott Bloom wrote: > > 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... ?? > > The problem I have with this oft-recurring formatting discussion is > that it's advertised as a big benefit, sometimes > downplaying its cost. It doesn't help me all that much to have > familiar formatting and naming in a translation > unit; that consistency is dwarfed by the effort needed to understand > the logical design of the code to reasonable > modify/refactor/maintain it. > > I think it's reasonable and harmless to clang-format new changes; I > continue to be unconvinced of the cost/benefit ratio > of reformatting all of our existing code. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
> 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... 😊 The problem I have with this oft-recurring formatting discussion is that it's advertised as a big benefit, sometimes downplaying its cost. It doesn't help me all that much to have familiar formatting and naming in a translation unit; that consistency is dwarfed by the effort needed to understand the logical design of the code to reasonable modify/refactor/maintain it. I think it's reasonable and harmless to clang-format new changes; I continue to be unconvinced of the cost/benefit ratio of reformatting all of our existing code. Agreed. I have moved to the "over all policy" of don’t check in crap code... 😊 And run your styler as you need to, on code you are working on, if it helps you understand it. And "try" to avoid checking in "format only changes" Scott ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
On 22 June 2018 at 19:39, Scott Bloom wrote: > 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... 😊 The problem I have with this oft-recurring formatting discussion is that it's advertised as a big benefit, sometimes downplaying its cost. It doesn't help me all that much to have familiar formatting and naming in a translation unit; that consistency is dwarfed by the effort needed to understand the logical design of the code to reasonable modify/refactor/maintain it. I think it's reasonable and harmless to clang-format new changes; I continue to be unconvinced of the cost/benefit ratio of reformatting all of our existing code. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
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 On Behalf Of Philippe Sent: Friday, June 22, 2018 09:12 To: development@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 + Scott Bloom 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 > On Behalf Of > Thiago Macieira > Sent: Friday, June 22, 2018 08:26 > To: development@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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 + Scott Bloom 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 On > Behalf Of Thiago Macieira > Sent: Friday, June 22, 2018 08:26 > To: development@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
On Friday, 22 June 2018 08:34:09 PDT Scott Bloom wrote: > 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. Right. I'm ok with the bot announcing formatting errors and getting people to agree on a single format. So long as we agree that there's no whitespace before a comma. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
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 On Behalf Of Thiago Macieira Sent: Friday, June 22, 2018 08:26 To: development@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
Im going to throw out my 2 bits .. Im not an active Qt developer, so take it
for what its worth..
Back in the old days (read CVS, pre git, pre svn, pre perforce) we had created
the ability to have the "Checked in format" vs the "Developer format"
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
-Original Message-
From: Development On
Behalf Of Frederik Gladhorn
Sent: Friday, June 22, 2018 00:47
To: development@qt-project.org
Subject: Re: [Development] clang-format
OK, so for now, my take-away from this thread is that we should simply create
nice commit-hooks that help everyone along. As a next step we can also enhance
the sanity bot with friendly messages.
I ran clang-format a few times over different parts of the code-base and I
agree that it sometimes ends up with stuff looking worse. Either use the opt
out for those parts or live with it.
Not having to debate the format again and again is a big win in my opinion.
Let's move the _clang-format file from qtrepotools to qt5.git:
https://codereview.qt-project.org/#/c/233051/
https://codereview.qt-project.org/#/c/233050/
Cheers,
Frederik
On mandag 18. juni 2018 11.04.33 CEST Frederik Gladhorn wrote:
> Hi all,
>
> as part of the closing ceremony of this year's Qt Contributors' Summit
> we agreed to start using clang-format, to have fewer discussions
> around coding style and rather focus on the actual code.
>
> I have not yet thought about all angles, how to best implement this,
> here are some notes:
>
> We have a clang-format file in qtrepotools. You can use it today,
> simply make sure it's in any parent directory of the files you are
> editing. I'd actually propose simply moving this into the root directory of
> qt5.git.
> https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format
>
> If you want to clean one file:
> clang-format -i myfile.cpp/h
>
> To clean a commit (only modifies the working tree):
> git clang-format
>
>
> Getting clang-format seems easy enough:
> On macOS: brew install clang-format
> Linux: install clang-format
> Windows: it comes with normal clang
>
> Then there is the tooling/workflow perspective. Creator and other IDEs
> have support (you may need to enable the beautifier plugin in about plugins).
> I imagine we add this to the sanity bot ("git clang-format --diff -q"
> should return empty, otherwise post a message).
>
> Local hooks are basically the same, any ideas how to best set up the
> git hooks appreciated :)
>
> And then there is the big question when we run it once over the entire
> codebase.
>
> Cheers,
> Frederik
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
OK, so for now, my take-away from this thread is that we should simply create
nice commit-hooks that help everyone along. As a next step we can also enhance
the sanity bot with friendly messages.
I ran clang-format a few times over different parts of the code-base and I
agree that it sometimes ends up with stuff looking worse. Either use the opt
out for those parts or live with it.
Not having to debate the format again and again is a big win in my opinion.
Let's move the _clang-format file from qtrepotools to qt5.git:
https://codereview.qt-project.org/#/c/233051/
https://codereview.qt-project.org/#/c/233050/
Cheers,
Frederik
On mandag 18. juni 2018 11.04.33 CEST Frederik Gladhorn wrote:
> Hi all,
>
> as part of the closing ceremony of this year's Qt Contributors' Summit we
> agreed to start using clang-format, to have fewer discussions around coding
> style and rather focus on the actual code.
>
> I have not yet thought about all angles, how to best implement this, here
> are some notes:
>
> We have a clang-format file in qtrepotools. You can use it today, simply
> make sure it's in any parent directory of the files you are editing. I'd
> actually propose simply moving this into the root directory of qt5.git.
> https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format
>
> If you want to clean one file:
> clang-format -i myfile.cpp/h
>
> To clean a commit (only modifies the working tree):
> git clang-format
>
>
> Getting clang-format seems easy enough:
> On macOS: brew install clang-format
> Linux: install clang-format
> Windows: it comes with normal clang
>
> Then there is the tooling/workflow perspective. Creator and other IDEs have
> support (you may need to enable the beautifier plugin in about plugins).
> I imagine we add this to the sanity bot ("git clang-format --diff -q" should
> return empty, otherwise post a message).
>
> Local hooks are basically the same, any ideas how to best set up the git
> hooks appreciated :)
>
> And then there is the big question when we run it once over the entire
> codebase.
>
> Cheers,
> Frederik
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
