Java var Should Be A Code Smell
The var keyword should never have been added to the language and should instead be a code smell.
I am a fan of Java and have been using the language since the 1.1 (February 1997) release version. Java’s ‘write once and run anywhere’ has always been one of the most beneficial features of the language since its inception. The preexisting framework that accompanied it was revolutionary and immensely useful to allow developers to build application more quickly. The standards built into the language helped make it easier to leverage and build tools around it. As the language evolved, it and the framework become increasingly better. Through the years, the language has had its benefits and problem areas but overall has become a great language to develop with.
Oracle’s purchase of Sun Microsystems (January 2010) was one of the scary moments in the future of Java. When this occurred, it became unclear what would happen to the language, because of Oracle’s license changes to control and increase revenue from Java. Oracle has always been bad for Open Source and this was one action that came very close to severely damaging the future of the language. Luckily Sun was smart in open sourcing Java and the OpenJDK stepped up to the challenge. Thank you OpenJDK and the Open Source community.
In recent years however, the addition of the var keyword seems to be a bad addition to the language. It was added in Java 10 (March 2018) and really opens the door to a code smell.
Get Stephen Paulin’s stories in your inbox
Join Medium for free to get updates from this writer.
It’s design is to infer the variable type using the initializer. This means it will define the object type for the local variable using what is on the right hand side of the equals sign.
//A string definition
String aString = "My String";// Using var for the string definition
var aString = "My String";
As the example shows, these are equivalent and the var is suppose to make this easier to read. Many tools that scan your code (e.g. SonarQube) will report the first code block as a defect and will push to use the var keyword instead.
This is a bad practice and should actually be a code smell. Using var is hiding the type from the person reading the code and will require them to have to figure out what is being done. Code should be explicit, and remove any ambiguity to improve maintainability. By using var, it forces the developer to have to figure out what the type would be. Also if the author doesn’t use it properly, it can be much more difficult to interpret the type. For example, most function return types are unknown. Similarly polymorphism and generics will cause much more confusion in this context.
var obj = obj.someFunction( );
var car = new Mustang( ); //Mustang extends CarIn the above you’ll have no idea what the obj type is in the first call until you dig into the code for someFunction(). In the case of car you may think it’s a Car but the language will make it a Mustang. These types of things make maintaining the code much harder over time and the readability more complex.
I can only speculate what went into the acceptance of the Java Enhancement Proposal 286 (Local-Variable Type Inference). The Java Enhancement Proposal makes a strong case for why this is beneficial, but it’s making assumptions that all code is well written, using simple types, contains no bad variable names and good documentation. Also it’s foundation is centered around writing less which most integrated development environments solve for you. If you’d been developing for any time you know that your integrated development environment will guide and auto-generate code for you. Also if you have to maintained someone else’s code, this type of syntax will frustrate you because it makes you have to work harder to read the code.
If you are coding in Java, do not use the keyword var. Configure your scanning tools to mark this as a code defect. Abandon the use of the var keyword and keep your code clean, descriptive, easier to maintain and self documenting.
