Thank you David. Your opinion about any *future* change to &&/|| style would be appreciated. ;-)
About "increased disruption to blame that makes understanding the history of our code harder": I think some tools like http://searchfox.org/ have considerably lessened the impact to blame, because they make it so easy to skip over style changes. E.g., in SearchFox, hover over the gray blame bar to the left, and click "Show latest version without this line", done! On Friday, February 17, 2017 at 10:25:58 AM UTC+11, David Baron wrote: > On Thursday 2017-02-16 15:11 -0800, Jeff Gilbert wrote: > > I would not assume that's necessarily going to happen without > > contention. Consistency is not a goal in and of itself. > > Using clang-format on the entire tree has the massive value of: > > * reviewers not needing to point out whitespace and indentation issues > > * reduced friction for new contributors (being able to use a tool > instead of repeatedly iterating on review comments) > > * reduced friction for existing contributors working in new areas > of the codebase > > which outweighs indvidual style preferences or historic module > differences here. > > We should try to do something as close as reasonably possible to the > existing dominant style so that we disrupt annotate/blame the least. > > > As for the proposal to switch to start-of-line && and || -- I > wouldn't want to see us try to make such a change *before* we > clang-format the entire tree, because we'll just create an > inconsistent mess that makes it harder to figure out what the local > style is. I'd be slightly more willing to consider it *after* we > clang-format the whole tree (or simultaneously, which is perhaps > better for blame since there's only one revision to skip), but then > we need to balance it against the cost of the increased disruption > to blame that makes understanding the history of our code harder. > > -David > > > 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-pl...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
