Hi again Nick,
Someone made me realize that I didn't fully read your message, sorry for that.
I now see that as well as &&/||, you have grepped for other operators, and
shown that the overwhelming usage is to put all of them at the end of lines!
In light of this, and from what others here&elsewhere have discussed, I'm now
thinking that we probably should indeed just update our coding style with
whatever is used the most out there, and model our "Official Formatter" on it.
Another thought, if technically possible:
If our main repository is going to always be under the control of some official
clang-format style, it should be possible for anybody to pull the repository,
and use a different formatter locally with their favorite style. And when
pushing, their modified code could be automatically reformatted with the
official formatter -- Everybody feels good when programming! :-)
Cheers,
Gerald
On Friday, February 17, 2017 at 5:16:42 PM UTC+11, Nicholas Nethercote wrote:
> I personally have a strong preference for operators at the end of lines.
> The codebase seems to agree with me, judging by some rough grepping ('fff'
> is an alias I have that's roughly equivalent to rgrep):
>
> $ fff "&&$" | wc -l
> 28907
> $ fff "^ *&&" | wc -l
> 3751
>
> $ fff "||$" | wc -l
> 26429
> $ fff "^ *||" | wc -l
> 2977
>
> $ fff " =$" | wc -l
> 39379
> $ fff "^ *= " | wc -l
> 629
>
> $ fff " +$" | wc -l
> 31909
> $ fff "^ *+$" | wc -l
> 491
>
> $ fff " -$" | wc -l
> 2083
> $ fff "^ *-$" | wc -l
> 52
>
> $ fff " ==$" | wc -l
> 1501
> $ fff "^ *== " | wc -l
> 161
>
> $ fff " !=$" | wc -l
> 699
> $ fff "^ *!= " | wc -l
> 129
>
> They are rough regexps and probably have some false positives, but the
> numbers aren't even close; operators at the end of the line clearly
> dominate.
>
> I will conform for the greater good but silently weep inside every time I
> see it.
>
> Nick
>
> On Fri, Feb 17, 2017 at 8:47 AM, <gsqu...@mozilla.com> wrote:
>
> > Question of the day:
> > When breaking overlong expressions, should &&/|| go at the end or the
> > beginning of the line?
> >
> > TL;DR: Coding style says 'end', I&others think we should change it to
> > 'beginning' for better clarity, and consistency with other operators.
> >
> >
> > Our coding style reads:
> > "Break long conditions after && and || logical connectives. See below for
> > the rule for other operators." [1]
> > """
> > Overlong expressions not joined by && and || should break so the operator
> > starts on the second line and starts in the same column as the start of the
> > expression in the first line. This applies to ?:, binary arithmetic
> > operators including +, and member-of operators (in particular the .
> > operator in JavaScript, see the Rationale).
> >
> > Rationale: operator at the front of the continuation line makes for faster
> > visual scanning, because there is no need to read to end of line. Also
> > there exists a context-sensitive keyword hazard in JavaScript; see bug
> > 442099, comment 19, which can be avoided by putting . at the start of a
> > continuation line in long member expression.
> > """ [2]
> >
> >
> > I initially focused on the rationale, so I thought *all* operators should
> > go at the front of the line.
> >
> > But it seems I've been living a lie!
> > &&/|| should apparently be at the end, while other operators (in some
> > situations) should be at the beginning.
> >
> >
> > Now I personally think this just doesn't make sense:
> > - Why the distinction between &&/|| and other operators?
> > - Why would the excellent rationale not apply to &&/||?
> > - Pedantically, the style talks about 'expression *not* joined by &&/||,
> > but what about expression that *are* joined by &&/||? (Undefined Behavior!)
> >
> > Based on that, I believe &&/|| should be made consistent with *all*
> > operators, and go at the beginning of lines, aligned with the first operand
> > above.
> >
> > And therefore I would propose the following changes to the coding style:
> > - Remove the lonely &&/|| sentence at [1].
> > - Rephrase the first sentence at [2] to something like: "Overlong
> > expressions should break so that the operator starts on the following line,
> > in the same column as the first operand for that operator. This applies to
> > all binary operators, including member-of operators (in particular the .
> > operator in JavaScript, see the Rationale), and extends to ?: where the 2nd
> > and third operands should be on separate lines and start in the same column
> > as the first operand."
> > - Keep the rationale at [2].
> >
> > Also, I think we should add something about where to break expressions
> > with operators of differing precedences, something like: "Overlong
> > expressions containing operators of differing precedences should first be
> > broken at the operator of lowest precedence. E.g.: 'a+b*c' should be split
> > at '+' before '*'"
> >
> >
> > A bit more context:
> > Looking at the history of the coding style page, a certain "Brendan" wrote
> > that section in August 2009 [3], shortly after a discussion here [4] that
> > seemed to focus on the dot operator in Javascript. In that discussion,
> > &&/|| appear in examples at the end of lines and nobody talks about that
> > (because it was not the main subject, and/or everybody agreed with it?)
> >
> > Discuss!
> >
> >
> > [1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
> > guide/Coding_Style#Control_Structures
> > [2] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
> > guide/Coding_Style#Operators
> > [3] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
> > guide/Coding_Style$compare?locale=en-US&to=7315&from=7314
> > [4] https://groups.google.com/d/msg/mozilla.dev.platform/
> > Ji9lxlLCYME/zabUmQI9S-sJ
> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
