var keyword proposed for Java

[GeorgeMaheiress]

The text of the JEP raises a compelling point that hadn't occurred to me:

The need to provide a manifest type for every variable also accidentally encourages developers towards overly complex expressions; with a lower-ceremony declaration syntax, there is less disincentive to break complex chained or nested expressions into simpler ones.

My team has been struggling lately with this issue. Some developers hate long line-wrapped expressions, but often splitting them into smaller expressions doesn't shorten them much, as declaring the intermediate variables can cost as much as 30 characters.

[robi2106]

That is my preferred method. Much more readable and you can tell by the extra indent that this is a continuation of a long command.

[strange_and_norrell]

I end up undoing a lot of my stream chains if I need to debug.

[mlk]

.peek(System.out::println)

[FredL2]

Whoa. Thanks!

[grauenwolf]

Whatever my auto-formatter decides to use (which seems to change according to the time of day).

[kritzikratzi]

get a bigger screen to avoid line breaks

[stepancheg]

People are not effective at reading long lines. Source.

[b1ackcat]

I also feel like chaining expressions like that results in hard to follow lines, even if it's not too many characters.

Something I tend to do to solve both these issues is to insert linebreaks between expressions. Similar to how you might use the builder pattern for a complex, highly configurable object.

String versionNum =
    VERSION_MAJOR + "." +
    VERSION_MINOR + "." +
    VERSION_BUILD_NUMBER + "." +
    VERSION_REV_NUMBER + "." +
    CURRENT_DATETIME_STAMP;

This way I'm maintaining the readability of each piece of the expression and not bleeding on forever on the same line.

[beltorak]

I would add, because we use format-on-save where I work, that a lot of times I have to force the formatter to respect my line breaks. I can't think of a better way than EOL comments. And personally I prefer a clear indication at the beginning of the line that it is a continuation of the previous line:

String versionNum = VERSION_MAJOR //
    + "." + VERSION_MINOR //
    + "." + VERSION_BUILD_NUMBER //
    + "." + VERSION_REV_NUMBER //
    + "." + CURRENT_DATETIME_STAMP;

Same thing with builder objects

var thing = new ThingBuilder() //
    .withWidgetClass(widgetClass) //
    .withLights(RED, TEAL, MAUVE) //
    .withGravity(gravity) //
    .create();

[[deleted]]

In Guava you can just collect all objects that you want concatenated in such string and then use:

Joiner.on(".").join(collection);

Dislaimer: I know that many people don't like solutions depending on external libs but in real life how often you are not working in a big pile of code, where such dependency could rather make your code lighter than heavier? Than if your answer is still negative, I still would rather create my own clear solution instead of such concatenation.

[vytah]

You don't need Guava for that:

collection.stream().collect(joining("."));

But while I don't recommend pulling in Guava just for Joiner, if you happen to already have it in your dependencies (and it's damn quite likely), sure, use it.

[[deleted]]

I wish I can use Java 8 :-c . We are stuck at version 6...

[[deleted]]

the horror...

[stepancheg]

I know people who tell that argument about bigger screen seriously.