I use IntelliJ IDEA as my Java IDE. I started using it back when it was demonstrably superior to every other Java IDE. Time has passed and it’s still superior but not nearly by the same margin. Thanks to the Eclipse plug-in system and the Sun push on NetBeans the other IDE’s have passed it in scope of functionality. But there’s still one way in which it stands far, far, far above the others. Code inspections. If the .Net guys have already tuned out, please don’t, Jetbrains (the guys behind IntelliJ) also sell a product called ReSharper. ReSharper is a Visual Studio plug-in that provides similar functionality for C#.

Real-time code inspections have proven invaluable to me to keep me from making bone-headed mistakes. But where they’ve really shown their worth is in evaluating other people’s code. In consulting you run into code that comes from everywhere. From internal teams, sub-contractors, amateur developers, client internal development teams and open source projects. The quality of the code varies greatly.

What do I mean by quality? It’s often hard to define. There’s a phrase called “code smells”. Usages and implementations that have a reek to them. What it boils down to is consistency and simplicity without extraneous code. It’s methods and class names that fit a set pattern. It’s small methods. It’s the removal of properties and methods that no longer serve a purpose. It’s comments.

Code that smells, that has a low level of quality, often has more serious problems. An inconsistent naming pattern rarely is a defect in and of itself. But it makes you think the inattention to detail extends to the rest of the code base. And it usually does. Most IDEs provide some level of real-time inspections now a days. IntelliJ goes deeper. It will tell you if someone opened a resource (database connection, file stream, etc.) and never closed it. In code with a poor level of quality you’ll see these serious errors at a much higher rate then in “clean” code.

My personal approach has been to build inspection profiles. For code I’ve been asked to quickly audit, I activate inspections that only search for “serious” problems. Items that almost always lead to actual defects. It isn’t until I’m leading a team that I step up the code inspections to hit the “softer” problems, like naming standards.

You don’t have to use IntelliJ (or ReSharper) to inspect your code. On the Java side there’s PMD and CheckStyle. On the .Net side there’s FxCop. Many development teams don’t want to invest in the time (for open source inspection tools) or money (for commercial tools). Given the issues I’ve seen reported by a single run of these inspection tools in the past, I highly suggest they re-think that viewpoint.