String reboot - (1a) incidental whitespace
Liam Miller-Cushon
cushon at google.com
Wed Apr 17 22:36:26 UTC 2019
On Wed, Apr 17, 2019 at 6:51 AM Brian Goetz <brian.goetz at oracle.com> wrote:
> I think we can assume that most of the time, users would prefer that the
> opening delimiter line up with the closing one, especially if we are
> essentially forcing them to put them on their own lines. Saying
>
> So the tradeoff here is, as Jim suggests:
>
> - More control over indentation
> - Less ability to lean on an existing convention
>
> Note that we seem to be leaning already towards using the position of the
> closing delimiter to determine whether there is a trailing NL or not. I
> think going all the way with this is something users could get their heads
> around. So it seems a reasonable option. What do we think?
>
Yet another stylistic choice is to break before the opening delimiter too:
String m =
"""
+--------+
| text |
+--------+
""";
While that formatting may be surprising at first glance, this isn't a
straw-person. There are a few benefits to that style:
* the delimiters are horizontally aligned
* renaming the variable doesn't create churn from having to re-indent the
string
* there's an arguable readability benefit: when embedding large chunks of
structured text into the middle of Java program, is may be helpful for the
distinction between the two parts of the file to be very clear, even at the
cost of some extra vertical space
Regarding formatting multi-line strings similar to braces, I'm still
thinking through why that's the best existing convention to borrow from. In
the code bases I've seen it's unusual to format other constructs in that
style, e.g. it's rare to see:
someMethod(
arg1,
arg2
);
Why are multi-line strings closer to constructs with braces than to other
expressions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190417/9ff39f41/attachment-0001.html>
More information about the amber-spec-experts
mailing list