On Fri, Feb 17, 2017 at 4:24 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp>
wrote:
>
> Point 5: We should set up a "Flag Day" to convert the source tree into the
> official format THAT IS SUPPORTED by the mechanical converter/formater, and
> change the source code in one sweep.
>
This seems like it places an enormous amount of trust in the tools not to
accidentally make semantic changes.
FWIW, when we converted NSS entirely to clang-format, we actually checked
that the compiler was producing the same output for the pre- and
post-formatted
versions and at least did some cursory review of the patches themselves. It
might make more sense to do this in stages.
-Ekr
>
>
>>> Cheers,
>>> Gerald
>>>
>>>
>>> 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@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
