A bit about Java code conventions

Fri, Mar 7, 2014

Most commonly used set of Java coding conventions comes from Sun Microsystems and it is still available on Oracle website. The document describes many important aspects of formatting, naming conventions etc for Java.

However, for most of the teams it is not enough for two major reasons. First of all, the document has become quite outdated in some cases as it is has been created back in 1999. Things like maximum of 80 characters per line, when most of us use full HD monitors, does not seem right. The other reason is that Sun’s code conventions still leaves a lot of freedom and it is easier to maintain and read the code written in the similar fashion. This is why many teams decide to create additional code conventions on top of the Sun’s document adding more specific things.

In this post I am discussing two of the Java code conventions which are not part of the mentioned official Java code convention, but which are often added on top of it. These two are: keep all variables in the code as „final” and using „this” for every field and method access in class.

• keep all variables in the code as „final”

  It is definitely a good idea to set all class’ fields as final whenever possible. It makes objects simpler by decreasing the number of possible states and for some it can make object immutable.

  On the other hand I cannot see any advantages of using „final” for all parameters of the methods. I do not think it helps with readability. I think, it actually ruins it in many cases because methods signatures are much longer and need breaking a line.

  Someone may argue it stops us from reassigning the variable from parameter, but the reality is that if someone would like to do this, he or she will remove “final” keyword and none of the tools will complain about it. IDEs like Eclipse can add „final” keywords for every parameter of the method, but it will not stop you from removing it and do bad things 🙂 . Actually, static code analysis tools (like Sonar) can warn you if you reassign the method parameter, but for these tools it does not matter if the „final” keyword was in place earlier.

  For variables other than method parameters and class fields I believe it depends on the specific case and there should be no hard rule, just common sense.

  • using „this” for every field and method access in class

    From my perspective using “this” everywhere is overkill. I believe it harms the readability by introducing additional content and adds no value. I can’t really think of any good reason to use „this” for all fields and methods invocations. All IDEs I know, clearly highlight the variables which are class fields, so it is really easy to distinguish between local variables and class’ fields.

    I believe we could just use common sense and write “this” when we think it really clarifies something (e.g. fields assignments).

These rules may seem not important, but it is worth to have in mind that we spend much more time reading the code than actually writing it. This makes any, even small readability improvement valuable.