Soo….you are thinking about adding or changing a Java style guide for your team? Do you stick with the tried-and-true Sun guide? Or is it too outdated now that it is twenty years old? What about Google style? But those two-space indents! Maybe AOSP? Twitter? Could you just accept the default that comes with IntelliJ?

Aaaaaagh!! Too many questions!

Let's take a step back

You have options. And, in 2019, none of the options widely available really address Java 8+ features like lambdas and streams. You will likely have to choose a foundation and evolve from there. Here are some of the options:

The Original Sun Java Style Guide

Google’s Java Style Guide

Android Open Source Project (AOSP) Style Guide

Twitter’s Java Style Guide

The JavaRanch Style Guide

Food for thought

Before going through the options and deciding, I think there are three steps you should follow.

1. Define your goal

Of course we all want to work on code that is consistent. In which case, any of the options are fine. But what is your actual goal for having a style guide? To share the code outside your team? Maybe outside your company? Or maybe you have multiple goals?

In my current team, we defined our goal as something like 60% consistency (so mostly we don't care as long as we have a style guide), 30% so that we are consistent with a couple other teams we work closely with, and to allow for our devs and theirs to work across team boundaries fluidly, and 10% for the sake of what tooling is available to support insuring that the code style is followed.

You may have other considerations.

2. Consider the environment

By this, I mean consider the places you look at your code. I'm guessing you perform code reviews. How? In Gitlab? That's a pretty good environment for viewing code and you may not care that much which of the styles you choose.

Do you want to be able to view it in a tool like FishEye? Does code ever make it into your Jira cards? What about on mobile? Do you ever look at code there? Does anyone ever open your code in a plain text editor?

It may be wise to think about these things and consider what long lines might do, or similarly what using up a lot of vertical space could do.

3. Consider tooling

Finally, how will you support code style in your project? If you use a build tool like Maven, there are some plug-ins like the fmt-maven-plugin to autoformat code when builds are ran (fmt-maven-plugin uses Google style).

That may feel a bit extreme. You may be comfortable with just letting your IDE support this, in which case you would want to get a hold of an XML file for the code style settings that you can import into Eclipse or IntelliJ.

It's really up to you.

Thoughts on lambdas and streams

All that being said, you also probably want to grapple with how to approach Java 8+ features like lambdas and streams. I asked Stuart Marks what Oracle is using. Marks is a Consulting Member of Technical Staff for Oracle and a Java evangelist.

Marks (perhaps unsurprisingly) had a lot of thoughts!

So there you have it. Loads of great advice for modern Java!

Just, whatever you do, please don't get stuck arguing spaces over tabs!