Jeff, I see you're opinionated against consistency. :-) Or you think there are other more important things? Anyway, I'm not exactly sure what you're advocating. Could you please elaborate?
On Friday, February 17, 2017 at 10:11:25 AM UTC+11, Jeff Gilbert wrote: > 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, <gsqu...@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-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
