Saturday, June 14, 2008

Keeping out Bad Code

Our needs for keeping out bad code may be different, but finding the time and tools for supporting this process is still a challenge for many software projects.

There are some good tools that are helping:

For Java,
Find Bugs

For C#,

These tools fall short in different ways. Some tools act like the overly verbose, picky lint. This can be good your project is built from the ground up with an agreed set of rules to enforce. Rules are good for keeping out well-defined behavior, but not necessarily good at finding "funky" or bad-smelling code.

Other tools take a more 'screening' mindset. The tools have the sense that you might want to know how code quality metrics are changing over time and can be integrated with build processes such as maven or cruise control.

Almost none of the tools have been designed for doing a quick but comprehensive peer review. Crucible might be an exception.

Overall, these sets of tools tend to stick to a more conservative set of rules. Steps into code smell detection has seen timid, but has seen budding support in the tools. But as always, it is hard to define these as rules because the answer always ends up being "it depends".

My take for dealing with design problems has been with software visualization:

As part of my research, I have developed a tool that examines C# byte-code and produces mini-diagrams of source code that can be screened for design problems.

No comments: