Static code analysis technics.


This page is the summary, of my post on static code analysis technics.

First of all, static code analysis method, can be use at several step in the development process :

  1. During code editing, in the IDE
  2. At code sharing time : pre-commit check in the source revision control
  3. Automatically on a regular basis or on demand (CI)
  4. at release time to ensure quality or check point approach.

All this approach should not be opposed and can be used in parallel.

It’s important to know what can be done and when.

Code editing : in the current IDE (netbeans, eclipse, ..) you can easily have your library, even application under ‘edition’. That means, that all analysis tools (static, and even dynamic) can use all the informations contained in the source files, and the one collected during test run, or application run.  But due to memory/response time expected by the end user, most of the time it’s very basic analysis, or a filtered analysis (only critical errors, …)

Code sharing : at commit time, you can mainly do syntax check. At least for scripts, xml, properties file, php you can ensure the syntax is valid, and for exemple ensure the encoding of the file. But you can not (should not) have more complex analysis because it takes time, and it will either slow down the team,  or create a dependency between your source revision control tool (svn) and your build tool (maven). Each time you change something in your build mechanism, you should update your svn server for example,….In some circounstance, when you want to garantee very high code quality repository, you can do it.

Automatic checks : these checks, are the most powerful, well used. On a regular basis (each day, each week, each release,…) they can analyze your  source code. Doing analysis on a regular basis, as two goals :

  • you have a zero default application, it will ensure you stay on track
  • you have a enhanceable application, it will allow you to know the trend, and to be on track, in your quality quest.

Analysis of results is complex, and identifying the root cause of your problems is not easy. So, don’t expect and don’t do a deep analysis of daily result, but do it on a regular basis (once a month,..) in order to check if you previous action show benefit, and if you don’t discover a new root cause.

at release time :  code analysis can be use as check point before doing a release .. but most of the time it’s too late …

It’s important when feasible to use the same tool at all the step.

For example PMD can be use in the IDE (in only critical error mode), in the CI, or automatically in full mode (to identify bad coding practices, and enhance the team coding skill),  and at release time in critical error mode, to reduce the risk.

Among the code analysis tools, we can define 3 families :

  1. code quality : pmd, javancss, …
  2. application quality : jdepend, ….
  3. bugs finder : coverity, findbugs, …
  4. aggregator, battle plan : sonar

All these tools can be define in a ‘quality quest’ category, but I’m trying to define a more precise hierarchy in order to help the reader to find his path.

The code quality family : in this category I’m putting all the tools working on the syntaxe, documentation in order to ensure the code is easy to read and not too complex. Also, I include all the tools checking the standard syntax mistake. These tools work at the file level, and can be run on only one file.

The application quality : these tools, try to identify bad class design for example, bad packaging, …. For example, if you have cycle in your classes, …. So, these tools requires the full file set in order to identify such cycle, such mess 🙂

The bugs finder: these tools,  try to ensure all the possible path in your code are safe. So, they try to garanty that no Null pointer execption, no division by zero, …. will arrive at run time.

The aggregator :  The key of the success, is to identify the roots cause of your issues, or the more critical ones. When you run all the tools, you have hundreds of reports, thousands of data to sort, to identify, to analyse. You can do it on a regular basis, but it cost you time. For example, to dig among a project of 200.000 lines of java, well build  and packaged (so you can easily plug all the tools), it took me 3 full days to identify some root causes.  Using tools like sonar, help you to spot such cause.

Also, it’s very important to compare trend of the metrics over time.

For example, the best mistake I’ve seen :

1) initial situation : crap code, no test at all, buggy at run time.

2) Management asked to add unit test , at least 50%.

3) developpers did it …. they reach 55% ….

4) you know what : crappest code, more bugs, slowest code ….

Why, because the code was not design to be test, so, developers to add test add more dependencies among classes, puts all method to public for test reason, other dev use the new public method in order code part for hacking some behavior ….. a full mess at the end.

The good point, is when i’ve run all the tools at different point of time (thanks svn ..) , so basically over 3 months, every 2 days, the trend of the differents metrics show me the whole pictures, and the evolutions of all metrics ….

Conclusion  : drop last 3 months code, and refactor existing code before adding bad tests….  and train your team to write good tests !

4 Comments (+add yours?)

  1. col brakey
    Mar 04, 2010 @ 15:13:00

    I like it :). Thank you for that, however my thanks don’t end there. I suffer from color blindness (protanopia to be exact). I mainly use Konqueror browser (no idea if that is important), and many web pages are hard to understand due to a problematic range of colors used. On this site, as the choice of colours is reasonable, the design is very clear and straightforward to comprehend. I am not sure if it was a premeditated and mindful deed, or simply a lucky break, but you have my gratitude.

    Reply

  2. Lawn care Newark
    Mar 06, 2010 @ 20:29:36

    Well I found this on Digg, and I like it so I dugg it!

    Reply

  3. sykotik
    Mar 10, 2010 @ 23:00:01

    You have tested it and writing form your personal experience or you find some information online?

    Reply

    • ouelcum
      Apr 22, 2010 @ 07:18:16

      Personal experience on several project. small, medium & big ones.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: