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
Android Open Source Project (AOSP) 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.
Scott Shipp@scottashipp
@BrianGoetz @stuartmarks Is "Sun Java Style" what the team is using for code style on the latest features or is it something else? Do you have any advice toward styling functional code?17:54 PM - 17 Jul 2019
Marks (perhaps unsurprisingly) had a lot of thoughts!
@ScottAShipp @BrianGoetz Yeah pretty much but as you know it’s way out of date. There has been some effort to update it but not completed yet. By “functional code” I guess you mean lambdas and streams? Here are a few things off the top of my head (of course, my opinion only, etc.) 1/20:11 PM - 17 Jul 2019
@ScottAShipp @BrianGoetz • prefer method references to lambdas
• prefer expression lambdas to statement lambdas
• omit lambda parentheses & types for lambda formals where possible
• use short but evocative names for lambda formals
• prefer predefined functional interfaces (mostly j.u.function.*) 2/20:15 PM - 17 Jul 2019
@ScottAShipp @BrianGoetz • write stream pipelines with one op per line, with dots lined up at the start of 2nd+ lines
• break up pipelines at logical boundaries by storing intermediate collections in local vars
• indenting multi-line stmt lambdas in stream pipelines is an unsolved problem; avoid. 3/20:19 PM - 17 Jul 2019
@ScottAShipp @BrianGoetz • avoid side effects in stream pipeline ops
• use parallel streams only when you know you have a perf problem that can be remedied by using multiple cores
• if you pass a stream as a method arg, ensure it’s unconsumed, and assume the callee consumes it
4/20:23 PM - 17 Jul 2019
@ScottAShipp @BrianGoetz • only return unconsumed streams
• use a stream as a team-with-resources variable only when it clearly contains a resource that needs explicit closing
That’s what I got. 5/x20:26 PM - 17 Jul 2019
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!
Top comments (0)