I am part of a Java development team with a 6 week deadline. This necessitates writing a good deal of code very very quickly. However our development team has different styles of coding. Everything from name conventions to methods of abstraction differ among our team. Does anyone know of any documents that dictate "standards" for java?

To clarify, I was wondering if there was an organization that would dictate proper naming convention for variables and functions for example. This is paramount as with such a short deadline we can't afford to spend time trying to comprehend each others code.


There is such an organization: Sun/Oracle itself. The document is called Code Conventions for the Java Programming Language, and it describes most of the conventions you need. Just have everyone agree to read it and follow its recommendations.

  • 3
    This is a well known std, but don't be afraid to deviate from it where the team agrees. Being restricted to 80 characters in width can be painful for example. – Martijn Verburg Jan 22 '12 at 9:21
  • 1
    @MartijnVerburg the limit can prompt refactoring into methods and classes to avoid deep indentation. – user1249 Jan 22 '12 at 11:06
  • This is a convention, and might be a reasonable fallback, if you can't find an own agreement, but as the name states, it doesn't dictate - it is a convention. – user unknown Jan 22 '12 at 13:54
  • @userunknown You're right. I don't even agree with all of the conventions. But it is a good compromise given the timeframe of the OP. – Andres F. Jan 22 '12 at 14:50

I'm really tagging on to Andres's answer, and focusing on the aspect uniformly formatting the java code.

If you are using Eclipse, you can set its Java formatter to automatically format to the Java standard. The Eclipse formatter also has other helpful settings, such as the characters per line (i.e. how many characters per line before it breaks to a new line), and many others. Standardizing characters per line makes it easier to diff code written by different developers without having a lot of differences just from spacing and line breaks.

Finally, with Eclipse, after you have set all the settings you want, then export your formatter as a file which can be imported by every member of the team. So if you are using Eclipse, I highly recommend fully exploring all the options it will auto-format and code edit for you, and then sharing the settings with the entire team.

I would assume the other major java IDEs (IntelliJ and Netbeans) have a similar feature for exporting the format settings.

  • 2
    +1 Good answer as well! You can also install a plugin like Checkstyle and have it warn you when you break conventions. – Andres F. Jan 22 '12 at 4:12
  • We do this too. Preferences -> Java -> Editor -> Save options and enable format at save. The primary reason is to ensure that the source lines affected by a format happens as soon as possible to get the version control history as clean as possible (diff's again). – user1249 Jan 22 '12 at 9:23
  • Yes, I started doing this recently also. The only thing I'm not sure about, is that I selected the "remove unused private variables" on the save option. So while I am doing TDD, I find that frequently, my variables disappear because code got saved before I used them... but other than, this option has been great. – Sam Goldberg Feb 6 '12 at 1:29

This [different styles of coding] is paramount as with such a short deadline we can't afford to spend time trying to comprehend each others code.

Actually. It's not paramount.

After 30 years as a consultant, I've read a lot of code from a lot of customers. It's important to note that every customer (and often within a customer's organization) there are varying styles.

After reading so many styles, I've learned this.

Style Doesn't Matter

Please focus on writing code that always works, and writing unit tests that prove that it always works.

After you've shipped working code, you can dress it up if you've run out of bugs to fix and enhancements to install.

  • maybe it doesn't matter, but it's also very nice to have, and very easy to do. – Kevin Jan 22 '12 at 18:39
  • 1
    Style doesn't matter, but consistency matters. Inconsistent style makes maintenance of the software a lot harder. – Jesper Feb 5 '12 at 12:02
  • 5
    @Jesper: "Inconsistent style makes maintenance of the software a" tiny bit "harder". It's not a lot harder by any stretch. Opaque, bad, buggy code is a lot harder to maintain. Inconsistent styles in working code is just inconsistent styles. Some people have an accent, and you have to listen more carefully. Inconsistent styles is little more than a different regional (or national) accent. – S.Lott Feb 5 '12 at 14:07
  • 1
    Style doesn't matter in a global sense, but consistent style within a single team does matter. It won't make or break a project, but if it's just as easy to be consistent as to not, why not go ahead and be consistent? You code will be at least marginally better. – Bryan Oakley Feb 5 '12 at 19:16
  • 1
    "You code will be at" best "marginally better". And yes, it's almost zero cost and certainly zero risk. But. 100% test coverage is far, far more valuable that consistency. – S.Lott Feb 5 '12 at 20:57

Don't worry about picking some perfect universal standard. All you need is for your team to agree to one standard and stick to it. Make up your own if you wish, but be consistent.

Consistency improves collaboration, collaboration improves code.

Even if actual consistency doesn't help, the fact that your team worked together to come to an agreement is a Good Thing. Their inability to agree to something as simple as coding conventions says there may be bigger teamwork problems lurking under the surface.


The Sun Java CC mentioned above not only is 13 years old and some of its rules are outdated (like 80 characters per line), but also it does not define naming conventions, except for the most general ones (camel casing for classes, block capitals for static final variables and the like).

You need to define your own standards for different types of classes, like DAOs, EJBs, entities, whatever you use. The Sun Java CC is like an abstract base class meant for extending :)

  • I agree Sun's Java CC are a bit old, but it's just meant as a starting point. I assume the OP doesn't have a lot of time to waste defining its own CC, or he would have said that! (BTW, where I currently work they use a Sonar plugin configured to enforce the 80 characters limit -- so this rule is still alive and kicking in some shops). – Andres F. Jan 22 '12 at 14:53
  • Besides other reasons, readability is a factor. Having to scan a long distance across a line is much less efficient than scanning down. With well formatted code you can quickly scan over irrelevant code. – BillThor Jan 22 '12 at 15:08
  • If you're running into problems with 80 chars per line, either you've got amazingly long identifiers or you're putting unreadably much on single lines. The former is silly (can you not distill the gist down to less than that?) and the latter is an indication of an urgent need for refactoring. Autoformatting on save is great since then you no longer have to worry about formatting at all; the software handles it for you. – Donal Fellows Jan 22 '12 at 15:40
  • @DonalFellows Yes, in this day and age, the 80 chars limit is there to remind you to refactor, not because of small terminal screens. – Andres F. Jan 22 '12 at 16:10

As mentioned by others here, you can search online for 1 of the few popular 'style guides' for Java and persuade everyone in the team to stick to them. Some code checking tools in your favourite IDE might help to remind you when you aren't doing so.

However, sometimes politics is involved. I'm once in a situation before where the most senior developer in the team continues to do it his way even after someone mentioned a need to standardise. In such a situation, it maybe be better to observe his code style and follow him since he probably has the most knowledge about the code base and requirements and you may not want to waste time stepping on his toes even though he is being difficult. Which is what the rest of us did in that particular situation and I reluctantly follows.

So it's important to consider your situation as well.

  • What country is this? Sounds like a cultural thing. – user1249 Jan 22 '12 at 9:23
  • @ThorbjørnRavnAndersen He meanse to say that people can be resistant to change when "what they've been doing for so long works". Political in this sense is just "office politics" – Robotnik Feb 5 '12 at 23:25

Uncle Bob shows a more modern and current coding style in his book "Clean Code". Unfortunately it contains no list of items. You have to read it. He says himself that to see his conventions, you have to read his code. Uncle Bob is without doubt a kind of institution. The book is an excellent read anyway, so even if it's too late to read it now, read it asap.


What really matters in code is low cyclomatic complexity, small scope, high cohesion and choice of expressive identifiers. Given those, code becomes easy to grasp and such code is good.

I suggest you look into Spartan Programming.

Most coding standards tell you how to make poorly written code look pretty and most discussions on "coding style" are actually about formatting. Code formatting is about visually representing the structure of your code. It is trivial and automatable and has barely to do anything with coding style, because coding style is not about how you represent code structure, but about how you structure code.
There's a also a lot of religious wars about naming conventions, although really they are just a hack to work around poor design. A name is good, if it says what it means. The smaller and clearer your scopes, the easier it is to choose such a name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.