Agree On the Java Format in Your Team

When you’re building software professionally, you’re doing it in a team. Admittedly, some programmers work as independent freelancers, but the vast majority work in teams. That’s good, because programming in teams is more fun and you have a chance to learn from your colleagues.

Of course, there are also many challenges: you need to coordinate, plan, and communicate with each other, and agile processes such as Scrum or XP tell you how to do this. This book isn’t about teamwork—it’s about code quality, and we won’t go any further in this direction.^[54] We’re bringing this up because there’s a team challenge that has an impact on your code: formatting.

Code formatting is a topic that easily leads to heated debates, even when you talk about the same language. Already the length of a line of code can be discussed. Should a line of code be set to 80 characters as it has been traditionally or 120 characters because we have widescreen displays today? Maybe 100 characters is a good compromise? Probably the most famous discussion point is whether you should indent code with tabs or spaces. Few things are more controversial among developers. Ultimately, there’s no right or wrong here. The problem is that all team members need to agree on a consistent formatting style to avoid constant reformatting and even bugs.

Usually, as long as you find a format everybody can agree upon, it’s fine—at least as long as you don’t waste countless hours trying to reach an agreement and creating corresponding configurations in your IDEs.

A better way is to avoid all discussion and use an industry standard. The Java code conventions that we’ve mentioned a few times are a good start, but they’re comparably brief and they haven’t been updated in a while. That’s why we recommend you resort to the Google Java Style Guide,^[55] the Java formatting guidelines by Google. Essentially, they’re an updated version of the Java Code Conventions with more sensible defaults. If that works for formatting all Java Code at Google, chances are it’ll also work for your team. The kicker is that there’s Google Java Format,^[56] a tool that checks and enforces this formatting. It’s best if you make that a part of your build process. Every time you make a change, simply run the tool and you’re done.