While working on a proposal for a new open source incubator project, it came as no surprise that the topic of which coding standards we should use came to the top of my task list as code formatting arguments were raised. In a flash of inspiration, I immediately provided the standard quick and concise answer: “Lets use the Oracle Java Coding Conventions standard.” Suddenly, the sun burned brighter and the birds took up in song as the brilliance of my efficient answer was delivered. Later in the day, when I had more time to consider the ramifications of my earlier answer, I pondered that perhaps I had been too simplistic in the view of what the Coding Standards means to me, my project, and the information technology industry as a whole.
So…let’s be honest with ourselves here. When push comes to shove, we do what we need to do to get the product out to the markets. How often do we tell ourselves, “who really cares if I used 5 or 10 spaces of indent” and “Why does anyone care that all of my variables contain a single letter?” We know that true “format” issues don’t really matter to anyone other than only the most critical of code reviewers. Also, we always tell ourselves that we will get back and fix all those little shortcuts we took (no comments, JavaDoc statements, commented out code, etc) just as soon as we have a little more time. Besides, we also all know that badly “formatted” code runs in production just as well “formatted” code…right?
However, as I found some free time to myself (aka the holiday period), I wondered if perhaps there were some things that are defined in high-quality Coding Standards that are perhaps a little more complicated that pure formatting. An example of one of those items is found below.
STRUCTURE GUIDELINE – “Avoid nested method call at all costs unless it is completely guaranteed not to throw an NullPointerException.”
Example #1
this.theInstance.theMethod.getMap.get(“key”);
In the above example, there is a good possibility that this efficiently written single line of code will return a NullPointerException to the caller. Code reviewers generally see samples of where this exception prone code is wrapped (usually later) as the example bellow shows.
Example #2
- try{
- this.theInstance.theMethod.getMap.get(“key”);
- } catch (NullPointerException npe) {
- log.error(npe.getMessage(), npe);
- }
- return npe;
When the NullPointerException message is inspected from the code above, the stack trace will tell you the line number that caused the exception (line 2), but cannot tell you if the Null object in this line was theInstance, theMethod, or getMap. Suddenly, we begin to realize that perhaps high-quality Coding Standards can help us write more “reliable” code.
In summary, delve deeper into the coding standards available in the community and consider if your projects should use code formatting tools such as Checkstyle (my current preference) in their efforts. It worked for me and hopefully it will work for you also.
An interesting consideration. Can’t wait to see your follow-up.