Coding Standard: String Literals and equals()

Coding Standard:

Use “some String literal”.equals(myString) instead of myString.equals(“some String literal”).

Justification:

It saves a null check.

Example of Violation:

String myString = getSomeString();
if ((myString != null)
  && (myString.equals("some String literal"))) {
    // do something important
}

Example of Correction:

String myString = getSomeString();
if ("some String literal".equals(myString)) {
  // do something important
}

Explanation:

When calling the equals method on a String object, there’s always a chance that the object is null. If you don’t check for it, you’re just asking for a NullPointerException. So there are two ways to handle this. Either check for null and then call the equals method if the String is not null, or turn around the logic and call the equals method on your String literal (which you know is not null). Both work fine. The latter saves you a null check and simplifies the conditional logic.

This standard can be enforced in JTest by enabling the PB.ISEM rule.

I haven’t found a rule in Checkstyle to enforce this. If anyone knows of such a rule, or a similar rule in another coding standards tool, feel free to post it in the comments.

See Also:

Automate Your Coding Standards Checks

---

Resources:

JTest is made by Parasoft.

http://www.parasoft.com/

Checkstyle is written by Oliver Burn and is an open source project at SourceForge.net.

http://checkstyle.sourceforge.net/

Effective Java Programming Language Guide is a book that deals with coding standards and best practices in Java. It is available at Amazon.com.

Technorati Tags: java

Advertisement

Automate Your Coding Standards Checks

While developers wish the whole world were Agile, it simply is not the case. I work for a company that does work for the government and our customer contractually obligates certain processes and even goes so far as to prohibit companies from bidding on projects unless they follow these processes. One of those involved coding standards. At first that didn’t sound all that bad. After all, most large companies have to impose some sort of standards and there are many good reasons to do so. The headache came when I discovered how they wanted us to enforce them. We were given an Excel spread sheet that listed dozens of standards and we were required to fill one out for each piece of code written. Worse yet, the standards were cross-language and obviously written by C programmers. As a result, we had to translate the standard from C to Java and/or decide whether it applied at all. Then you had to read the code, keeping all the standards in your head, and sign off that it met them all. If even the smallest bit of code was changed later you’d have to go through the entire checklist again. It was painful and absolutely killed productivity.

After filling out a number of these checklists and hating every minute I decided that there had to be a better way. This is the kind of tedium that computers are made to handle. Why should I have to spend time doing such a mind numbing processes when a computer could do it better anyway? I’m bound to miss things. I’m bound to get bored. I’m bound to just check off the list and sign it because I’m’ tired of the whole damn thing.

Thankfully there was some money in the budget for tools and so I started looking around to see what could alleviate my headache. I came across a great Eclipse based product from Parasoft called JTest. You can either buy it as a stand-alone IDE or as a plugin for Eclipse. It does automated generation of JUnit unit tests, runs those tests while reporting code coverage and has a collection of more than 400 coding standards that can be enforced with the check of a box. The nice thing is that all of them include an example of the violation of the standard as well as an example of how the violation can be rectified. Beyond that, it has a justification for why the standard is a good idea and references to authors like Joshua Bloch and others who have written about the standard. This is extremely helpful in deciding whether the standard is one that you want to follow or not.

After we got JTest installed I sat down with a co-worker and went through every standard in the list and checked as many we thought we could possibly stand. Over the next couple weeks of coding we had to tailor this list a bit as we found that we had standards that contradicted each other. We also found that some were so annoying that they just had to go. By the time we were done, we had covered everything that was in the Excel spreadsheet and a whole lot more. Our process still required that we fill out the form, but now that we had the automated standards, we simply pre-filled the form and if the code passed the automated test, then we filled the details of what code was being reviewed, the date and the reviewer and that was all. This was an immediate boost to productivity.

Many months later I started looking into some open source coding standards tools. While I found some tools that had promise, they just weren’t up to par with what I was getting in JTest. That is no longer the case. There are some very significant open source tools to do automated enforcements of coding standards. One of the more popular ones is called Checkstyle.

JTest has two advantages over Checkstyle. First, JTest has significantly more pre-defined coding standards than Checkstyle. Both allow for defining your own standards and tailoring existing standards with various options including regular expressions. Still, it’s nice to have a pre-defined set so you can spend your time coding instead of defining coding standards. Second, JTest has an auto-fix feature that is paired to many of the standards. What that means is that for many of the simpler standards you can simply click on the coding standard violation, select Quick Fix from a popup menu and JTest will fix the violation automatically. Very nice.

Checkstyle two advantages over JTest. First, the cost. Checkstyle is open source and free. JTest is a closed source, commercial product and is not cheap. In many corporate environments this may not be a problem as it’s cheaper than other commonly purchased tools and there’s a perception that you simply buy what the developers need and don’t mess around with a cheaper tool that the developers are going to have to fight against and spend hours getting to work properly. There’s some truth to this, but with the exception of having to create coding standards rules for Checkstyle that might otherwise come with JTest, Checkstyle takes no longer to get up and configured than JTest does. Second, Checkstyle integrates into almost any developer tool you can think of and new integration plugins are being written for it all the time. When I first started using JTest it integrated into Eclipse and well, Eclipse. Now they’ve started expanding that list a bit, but it’s still not integrated with as many tools as Checkstyle. Worse yet, if you buy JTest and use it for coding standards in your IDE, you’ll most likely want to use those same coding standards in your automated builds to generate reports and status for the project as a whole, but JTest does not support this without an additional purchase of a even pricier JTest Server tool that supports command line builds. At the time of this writing there are Checkstyle integration plugins for Eclipse, Websphere Studio Application Developer (WSAD), IntelliJ, NetBeans, JBuilder, BlueJ, Emacs JDE, jEdit, Vim, Centipede, Maven and Ant. The wide-spread plug-in support makes it fit nicely into most any pre-existing development environment.

From the text above it may sound like I’m slamming JTest pretty hard. In some cases I am and the criticisms are justified. But it has to be taken into account that JTest is much more than a coding standards tool. It does automated generation of JUnit tests which is a incredible timesaver for augmenting developer generated test cases. It often finds cases that the developer missed and generates tests for a bunch of the cases that the developer knows that they should right tests for, but don’t because they’re so tedious to write. For instance, if a method takes an int, JTest will generate tests that call the method with large negative numbers, small negative number, large positive numbers, small positive numbers and zero. They are offering an IDE, based on Eclipse, in which things work well together and in this respect they’ve done well. While I’m always looking at open source solutions and there may be a day when there are open source ways of doing everything that JTest does, we’re simply not there yet. In the meantime, Parasoft offers a respectable product line and should be strongly considered if you’re in the market for a commercial IDE with some significant unit testing and coding standard features.

Regardless of whether it is JTest or Checkstyle that meets your financial and functional needs, I highly recommend looking into some sort of automated enforcement of coding standards. It relieves the developer of the tedium required for manual evaluation of adherance to coding standards and can contribute to an overall improvement in code quality.

Joshua Smith

Rational Pi Blog – https://rationalpi.wordpress.com/

---

Resources:

JTest is made by Parasoft.

http://www.parasoft.com/

Checkstyle is written by Oliver Burn and is an open source project at SourceForge.net.

http://checkstyle.sourceforge.net/

Effective Java Programming Language Guide is a book that deals with coding standards and best practices in Java. It is available at Amazon.com.
Additional Java Coding Standards Tools

PMB

http://pmd.sourceforge.net/

Find Bugs

http://findbugs.sourceforge.net/

JLint

http://artho.com/jlint/