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, <gsquel...@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-platform@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
