I would not assume that's necessarily going to happen without contention. Consistency is not a goal in and of itself.
On Thu, Feb 16, 2017 at 3:04 PM, <gsquel...@mozilla.com> wrote: > There's an ongoing effort to use clang-format to automatically format All The > Codes [1], so I think we should try and make sure we agree (or at least > settle*) on a coding style when it's going to be enforced everywhere. ;-) > > * I'm presenting my own preferences here, but in the end I'm fine with > complying with whatever we can all agree to live with. Consistence is more > important than personal preferences. > > g. > > On Friday, February 17, 2017 at 9:57:04 AM UTC+11, Jeff Gilbert wrote: >> I don't visually like ||/&& at start of line, but I can't fault the >> reasoning, so I'm weakly for it. >> I don't think it's important enough to change existing code though. >> >> On Thu, Feb 16, 2017 at 1:47 PM, <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
