On 09/06/2017 09:03 PM, Eric Rahm wrote:
As I said, I was hoping to avoid rehashing this point, but the general
consensus from the last rather contentious post [1] was that changing
from the prevalent style of the codebase for primarily aesthetic
reasons was hard to justify (points about readability were made on
both sides). Nick pointed out that our code base very clearly tilts to
the operators on the end of the line style [2].
This has already been discussed to a great length as you note Eric, and
like you I don't think rehashing the previous discussions is
particularly helpful.
Also, while I understand that people will certainly have (sometimes
strongly held) personal preferences, the Mozilla Coding Style isn't a
place where everyone's personal preferences can win, for the obvious
reason that these personal preferences are often mutually exclusive.
The interesting points to consider is the data that Nick alluded to in
the previous discussion about the existing prevalent style.
Also, the point you up about the pragmatic aspect of the need to be able
to use automated tools in order to manage our Coding Style is right on.
As things stand, the only viable option of such a tool that I'm aware of
is clang-format, and given the standing situation with regards to what
formatting options we can make that tool support in this case, I think
the pragmatic decision is to pick *one* option here for the placement of
operators across line breaks: either at the end of long lines or in the
beginning of the next line.
The combination of the above points makes me prefer adopting the
proposal to treat all operators like && and ||.
Carrying forward this wisdom for this case makes sense, but I'll admit
moving everything to the newline is certainly an option that would
provide a unified style which is my greater concern. I don't think we
could reasonably make that change until some sort of flag day when we
convert everything as the new style would clash with the prevalent
style. I also don't want to start a discussion about that again :)
Yes, I think once we get to a point where we format our code using
clang-format it would be much easier to argue for changes to the Coding
Style like this, but a discussion about that right now seems premature.
-e
[1]
https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/dLckkuFjBwAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/ErPunKZ_BwAJ
On Wed, Sep 6, 2017 at 5:18 PM, Mike Hommey <m...@glandium.org
<mailto:m...@glandium.org>> wrote:
On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote:
> Hi folks-
>
> *Note: Previously we've discussed the placement of logical
operators && and
> ||; a decision was made and I do not wish to re-litigate that here*.
>
> Currently we have a somewhat convoluted set of rules about where
to place
> boolean operators when breaking long lines [1]. Essentially we
say that
> logical operators such as `&&` stay at the end, but boolean
opertators such
> as `>` move to the new line. It's possible I'm misreading that
(others
> certainly have [2]).
>
> This is incompatible with tools like clang-format [3] which
support either
> leaving the operator at the end of the line or moving it to the
new line,
> but not a half and half approach. It is very unlikely we could
convince
> them to upstream such a change given we are the only
organization that has
> requested it.
>
> I would like to propose that we adjust our style guide to remove the
> distinction between logical operators and boolean operators for
the purpose
> of line breaking and use a unified style.
>
> *Examples*
>
> Current rules:
>
> if ((aArgument == 100) &&
> (anotherReallyLongArgument
> > 2000)) {
>
> Proposed change if we unify the rules, favoring the logical operator
> placement:
>
> if ((aArgument == 100) &&
> (anotherReallyLongArgument >
> 2000)) {
On a personal note, I find > 2000 as in the first sample more readable
than the latter. So much so that I'd actually prefer the logical
operators to be on the next line than boolean operator being on the
previous.
Mike
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
