Creepy Crawlies Anyone? When I think of the creatures that programmers have to battle everyday, the first one that pops up into my head is BUGS! We programmers HATE them. Cannot stand them. And we are a kind of bug zappers, going about killing bugs all over the place. I think even novice computer users would understand that I’m not talking about 6 legged insects, even though there ARE programmers who are able to kill those as well!
It’s unfair to address bugs as an issue outside the programmer which he valiantly attempts to fight against. On the contrary (and most commonly) bugs can be seen as mistakes and oversights of developers while giving life to a software (even though they can be caused by other reasons, like users misinterpreting what they actually want).
Well, in defense to all the programmers out there, making software is a complex task. Programmers have to battle certain demons while writing code. The developer has to figure out what to do, how to do it, all the while pleasing impatient users. This means the developer have to ensure that;
a) They don’t frustrate the users
b) Their code is ultra fast
c) The software can easily accommodate changes according to the user
d) The code is simple and efficient
So, with so much going on, developers tend to make mistakes and derive something unfavorable.
Traditionally, bugs are caught by Software Quality Assurance (QA) folks and they would file a ‘bug’ in the bug tracking software like Bugzilla and developers are obliged to fix them. Indeed, anyone would hate their mistakes to be made public and criticized by someone else. Therefore it becomes useful to do some form of checking and re-checking before the programs reach the bug police!
Bugs can be categorized into two
1. Bugs related to requirements – If there’s such bugs, that means the developer has not fulfilled what the customer wants. Either the developer has forgotten or wasn’t aware and has deferred the requirement specification. Since there’s no way to read the customer’s mind, the best way out of this pitfall is re-analyzing the specifications.
2. Technical Bugs – On the contrary, there can also be programming mistakes. In coding there are many different ways to fixing, but not all those ways are right (and some are just bare ugly). There are many things that can be done wrong technically. Unlike bugs related to requirements, technical bugs, in most cases, can be tackled. Luckily for Java programmers there’s tools like FindBugs and Checkstyle.
FindBugs is a tool which finds technical issues with the software by analyzing it. It was developed by the University Of Maryland, endorsed by giants such as Google, NSF and used by projects such as GlassFish and JSF. FindBugs is a Free and Open Source Software (FOSS) freely available under Lesser GNU Public License.
This tool does its finding by going through the generated class files and finding patterns of bugs similar to the bug patterns defined in its database. As a result, it’s able to find bugs in a very consistent and accurate way.
FindBugs looks for 3 types of problem patterns. Quoting from FindBugs site;
• Correctness bug – Probable bug. Apparent coding mistakes resulting in code that was probably not what the developer intended. Some examples are impossible casts, call to equals() comparing different types, equals method always returns false, JUnit TestCases having no tests, apparent infinite loops, bad comparison of nonnegative value with negative constant.
• Bad Practice – Violations of recommended and essential coding practice. Examples are hash code and equals problems, cloneable idiom, dropped exceptions, serializable problems, and misuse of finalize.
• Dodgy (or Style) – Code that is confusing, anomalous, or written in a way that leads itself to errors. Examples are dead local stores, switch fall through (no finally block), unconfirmed casts, and redundant null check of value known to be null.
In comparison to FindBugs, Checkstyle is a tool which looks for different kinds of bugs. Checkstyle is in contrast interested in bugs visible in the code (not bugs visible in the software). Checkstyle in coding standards are followed in the code and highlights them.
Checkstyle too is a FOSS freely available under Lesser GNU Public License. Examples of bugs include, checks for class names, method names etc. not conforming to some naming standard, checks for unused imports, checks for source files which are too long, checks for throws statements giving too broad exceptions like java.lang.Exception.
How to Use
- It’s possible to use both FindBugs and CheckStyle in two levels. The most common way to use them is as plug-ins for the popular Java IDE, Eclipse. Both FindBugs and Checkstyle have update sites. Users only have go to Help > Install New Software > Add on their Eclipse and add the links to their software. The software gets automatically downloaded and installed. Then enable these for your current project. Thereafter, whenever you code in your IDEs it automatically scans your code and the class files to find potential problems and alerts you of the errors.
- The other way is to attach these to the build processes. Both FindBugs and Checkstyle has plugins for the popular Java build tool Ant. Therefore, it is possible to run both these tools when building the project. This is especially useful when using continuous integrations nightly builds. With the correct settings, you can make sure that no undesirable build would be created in your software.
In both these tools it is possible to customize it to your own project specific standards. Both come with settings files (and a user friendly UI on Eclipse) which enables you to customize properly by enabling/disabling and changing the default set of checks.
Hope you would use these tools and improve not only your code, but also your skill as a programmer.
Have something interesting and IT related to share? email the email@example.com