Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

The 5 Static Code Audits every developer should know and use

By Mike Rozlog, Network World, 07/23/09

In today’s competitive market and economy, developers need every tool they can get to increase productivity, reduce cost and lower maintenance while ensuring proper execution in production. One of the more under utilized developer tools is static software audits.

The concept of static analysis has been around for years, and over the past few years tools to evaluate and diagnose the style of the code have matured. There are hundreds of software audits available to developers today in almost any language. These audits can isolate poor coding practices in various areas like Arrays, Loops, Coding Style, Design Issues, Duplicate Code, Naming Style, Performance, and many others. Inside each one of those top-level classifications is another full set of audits to be used by developers or their teams.

A quick word of caution, using audits can cause audit paralysis where the developers get overwhelmed by the tool reporting too many things to fix. I once looked at a 200,000 line application, small by today’s standards, and ran the full complement of 200+ audits. The report basically stated that I had over 350,000 violations that needed to be fixed. What, where, how… overwhelming!

One key to successful audit usage is defining a limited set of audits. This is usually different for every developer or team. Before embarking on an audit hunt, the developers should come to a common-goal regarding what they are trying to fix or solve. This takes a few minutes or in some cases hours, but the time is well worth it.

I always recommend developers and teams start small, pick a set of limited audits that can be used to fix various common issues and give a great return. It should be noted that before engaging in an audit hunt that the developers already follow common practices like SCM, Unit Testing, and hopefully a QA process.

The great thing about audits is they give information about code and how it is constructed. Just because the report states that line 100323 has an anomaly, it does not necessarily mean that a) it is a true problem, or b) it will actually cause a problem. A good tool should give the ability to mark a reported problem as verified; this can be done in comments or something to let the tool know that the area has been reviewed and is OK to continue without modification.

So when do you use audits? I recommend audits be run every single night or during an integration build to ensure good form, especially if the code is being developed from scratch or is a new project. I believe audits should be run at least once when performing Software Archeology on existing code, and should be run all the time during a refactoring process.

The five audits that I’m going to focus on are Numerical Literal in code, String Literal, god Method, Shotgun Surgery and Duplicate Code. When I present these to companies they always look at me and say the same thing, “Why those five?” There are many reasons but in general, once they are explained, they are easy to understand and at the same time they have real benefit.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.