It looks like the doc already specified this behaviour for ternary operator
line wrapping. For your proposal I’ve also added the following:
It is usually preferable to carry the operator for multiline expressions, with
the exception of some multiline string literals.
Does that work for you? The “usually” at least leaves some wiggle room, as
ultimately I would prefer this decision to be made by an author (even if a
general norm of carrying the operator is preferable).
I am concerned that this starts leaning towards being too specific, though. It
opens up questions like whether we should also be specifying spacing for loop
guards, conditions, casts, etc?
From: bened...@apache.org <bened...@apache.org>
Date: Sunday, 20 March 2022 at 21:37
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: Updating our Code Contribution/Style Guide
> We are talking about one extra line, not a dozen or more.
I think you are confused about the context. The case I was discussing often
means 10+ additional lines at each call-site.
> Once the code gets more real, it is faster to read the difference between (a)
> and (c)
This isn’t a great example, as if you are line-wrapping with multiple
parameters you should be assigning any computation to a clearly named local
variable before passing the result to the constructor (amongst other things).
We can perhaps highlight this in the style guide.
We also do not only produce multi-line computations in this context. If
constructing into a variable (where there is no such ambiguity), it is much
easier to parse parameters first without the concatenation operator preceding
them.
My point is simply that legislating on this kind of detail is a waste of our
time, and probably counter-productive. I don’t want to enumerate all the
possible ways we might construct multi-line computations.
Ternary operators are pretty clear, so maybe we can just agree to define those,
and leave the rest to the judgement of the authors?
From: Mick Semb Wever <m...@apache.org>
Date: Sunday, 20 March 2022 at 20:56
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: Updating our Code Contribution/Style Guide
> I support this too… leads to more noise in, and less readability of, the
> patch.
Readability of the patch is not harmed with modern tooling (with whitespace
being highlighted differently to content changes).
Legibility of the code (not patch) should always be preferred IMO. To aid code
comprehension, we should aim for density of useful information for the reader;
wasting a dozen or more lines on zero information density, solely to solve a
problem already handled by modern diff tools, is a false economy.
We are talking about one extra line, not a dozen or more.
It also improves the readability of the code IMHO.
> I would also like to suggest that an operator should always carry on line
> wraps
For the ternary operator I agree, however I am less convinced in other cases.
String concatenation is probably cleaner with the opposite norm, so that string
literals are aligned.
IMHO it works for string concatenation too.
The example that comes to mind is
a)
method(
"aaaaaaaaaaaaa",
"bbbbbbbbbbbbb",
"ccccccccccccc"
)
b)
method(
"aaaaaaaaaaaaa" +
"bbbbbbbbbbbbb" +
"ccccccccccccc"
)
c)
method(
"aaaaaaaaaaaaa"
+ "bbbbbbbbbbbbb"
+ "ccccccccccccc"
)
Once the code gets more real, it is faster to read the difference between (a)
and (c) than it (a) and (b).
