Static Analysis tools > Experience? No way


News: Static Analysis tools > Experience? No way

  1. The Heartache You’re trying to finish up some down-to-the-wire coding to get it over to your Testers, and your deadline is approaching. You have this one last class to change and it is a legacy class. This class was written before the static analysis tools were forced to be run on the code base. You go in to make a simple change like adding a null pointer check. You now execute the static analysis tool on the code and you have 30 violations — from incorrect naming of fields to Cyclomatic Complexity greater than the threshold. You have 2 options here: A) You take the time to fix all the violations, and leave the code better than you got it or B) You take the lazy / easier solution and try and beat the rules — take the easy way out and work around them. What do you choose? What should you choose? Read the full article at
  2. You could take any of the options but the root cause would have to be fixed. Most of the static code analysis results would point to a bigger issue in the lifecycle of the product. Refer
  3. In my research lab, we have worked during last few years on quality metrics dedicated to source code "production". ( ) It is almost impossible to set up a "universal" set of quality metrics that will be relevant for all projects. But it allows to set up to the following "process" 1- Use quality metrics to monitor activity 2- Compare the last report to those from the previous month. 3- If something is astonishing, investigate it using data mining tools 4- Once you understood what happened, decide if an action is required (improve process,rewrite piece of code, etc, ...) A metrics is usually very inefficient to decide if what happened was "good" or "bad". If you are not suspecting "inhomogeneity" in your developers' skill, it's easier and better to improve pre-existing process than set up a new one.