I'll not get into why I disagree with your points about format-the-world here. Let's leave that for elsewhere.
Here's my take on the example at hand: https://pastebin.mozilla.org/8979527 In this case, I do like the latter two best. (Old-style and simplification) On Thu, Feb 16, 2017 at 3:25 PM, L. David Baron <dba...@dbaron.org> 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, <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 > > -- > 𝄞 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
