One thing I like about trailing operators is that they tend to match
what you'd find in bullet-point prose. Here's a made-up example:
You can apply for a refund of your travel insurance policy if:
* You cancel within 7 days of purchase, and
* You have not yet begun your journey, and
* You have not used any benefits of the plan.
Over time my eyes have come to expect the conjunction on the right.
On Fri, Feb 17, 2017, at 07:28 PM, gsquel...@mozilla.com wrote:
> While it's good to know how many people are for or against it, so that we
> get a sense of where the majority swings, I'd really like to know *why*
> people have their position. (I could learn something!)
>
> So Nick, would you have some reasons for your "strong preference"? And
> what do you think of the opposite rationale as found in [2]?
>
> (But I realize it's more work, so no troubles if you don't have the time
> to expand on your position here&now; thank you for your feedback so far.)
>
> 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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
