> 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
> 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 cu
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
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 o
> 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 b
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
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
pornog
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 rev
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, eve
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 e
10 matches
Mail list logo
