TaskTracer has been developed continuously by OSU students and faculty for more than five years.  Many people have contributed to the TaskTracer codebase during this time, and some of these contributions were done hastily under deadline pressure, or under varying levels of supervision.  The result is a large codebase with areas which are difficult to maintain due to lack of consistency, comments, naming conventions, and complexity.  In this article, I will refer to all these “coding pitfalls” as lack of quality.

The dynamic nature of the TaskTracer codebase increases the difficulty to code with quality.  With requirements for new features or adaptations to new environments, much of the code must change.  As such, the software written without code quality in mind can slow down later maintenance and development drastically.  Many articles state that the amount of effort required to write quality code is much less than the effort required maintain poorly written code.  Most developers agree with this statement, but for whatever reason, low quality code is still committed to the repository.  Possible causes may be that developers don’t realize their code isn’t up to standards, or that they are in a hurry and intend to fix it later.

If it were possible to have a second pair of eyes look over recently committed code, potential problem areas could be spotted earlier and fixed.  A bit more effort would be required in the initial creation of code, but the cost to maintain the higher quality code would be reduced enough to justify the larger cost.  There are many obstacles to overcome in creating such a “peer review” system, including time constraints, human bias, and the inability to determine with precision the quality of code.  A software solution would be ideal in this scenario.

Improving Code Quality Via Static Analysis

Fortunately, there are several software tools which can perform a static analysis on software code to produce numerical metrics relating to code quality.  These tools put unbiased values on code quality – and require absolutely no human reading of code.  We have chosen NDepend for our static code analysis tool.

NDepend uses the wealth of information available in assemblies, debug files, and source files to calculate many code metrics with significant granularity.  A code query language (CQL) created by NDepend can be used to search the metrics for assemblies, types, or methods with low quality.  The product of running NDepend on a codebase is an unbiased view of the code.  This view will give developers and others a deeper, more complete understanding of the codebase, allowing for more informed design decisions and guidelines for refactoring and new development.  An example of information from an NDepend code analysis is displayed in the table below.  This table shows metrics on assemblies, such as lines of code, lines of comment, coupling, cohesion, and instability.

NDepend Code Analysis

Nightly Build

Building and testing the code nightly has always been an effective means of ensuring the codebase is in working order.  However, extremely complex and hard to maintain code can also build and pass unit tests, despite its undesirable nature.  To verify the quality of the code on a regular basis, NDepend has been grafted into the nightly build.  Every night NDepend runs against the most current code, which gives developers a feel for the evolution of code quality.  In the future, NDepend will also be used to warn developers that they have committed code which doesn’t conform to quality coding guidelines.  This will be done in an effort to keep developers conscious of the quality of code they commit.

Below is an image of the TaskTracer nightly build system, which employs TeamCity, with NDepend reports attached to builds as artifacts.  This system allows viewing of any current or previous report in just a few clicks.

NDepend In The Nightly Build

Current code analysis

NDepend metrics have already shown the TaskTracer team where “hot spots”, or code which lacks quality, are in the code.  Some of these spots are well-known trouble areas which have historically been hard to fix, and others are areas where little development work has been needed (so the problems had not presented themselves yet).  For example, the following image highlights sections of code which may be overly complex in a surface area map.  StateEstimator (residing in the CoreComponents assembly in the upper right hand corner) has been difficult to maintain in the past due to complexity.  This graph shows other assemblies which may be hard to maintain as well.

NDepend Current Code Analysis

Past Code Analysis

Several versions of TaskTracer have been developed prior to the adoption of NDepend.  Another future task for NDepend will be analyzing and storing data from builds at specific time intervals, then graph the data and see what trends appear.  Potentially interesting observations could include

• how the quality of code changes near release deadlines or around finals/midterms
• when the most code is committed to the repository
• how often refactoring has occurred
• how effective the refactoring has been
• what code changes led to the largest increase in quality

This information can be leveraged by management to make decisions regarding the focus of developers at certain times and phases of the project.

Specific NDepend Results

NDepend has many built in metrics which can be used right out of the box to gauge code quality.  The “Top 10” feature of the CQL language can show methods, types, or assemblies in most need of attention.  If a section of code violates quality standards, it may be fixed by a developer and run with NDepend again to determine how effective the fix was.  NDepend’s built in queries include a wide variety of code quality metrics, some of which are listed below.

Hard to maintain code-

Complex code where methods involve too much logic, too many paths to a return, too many types, or just too many lines can become hard to maintain.  Some of the more complex sections of the TaskTracer codebase even have redundant code that makes no logical sense (possibly due to hasty or inefficient bug fixes).  NDepend can help target complex methods so developers can refactor them into more focused and maintainable pieces.

NDepend Report for Hard To Maintain Code

Unused Code

NDepend can also show unused types, methods, and fields in TaskTracer.  These may be dead code which unnecessarily bloats assembly size, or they might be useful functions that developers weren’t aware of.  More importantly, unused methods may work in ways that have only been valid in the past – and using them again without modification may result in buggy code.  Awareness of unused code may prevent accidental bug introduction later, and removal will improve maintainability and quality of code.

NDepend Report for Unused Code

Lack of cohesion of Methods

Cohesion is a metric calculated from relations between methods and fields within a type.  If every method uses every field, cohesion will by high (and conversely, lack of cohesion will be low).  If fields are used only by specific methods, cohesion will be low.  A type with poor cohesion indicates that the type could easily be split into multiple types for increased maintainability.

NDepend Report for Cohesion of Methods

A Question of Metrics

The numbers provided by NDepend are extremely useful in determining general code quality efficiently and effectively.  However, even if code strictly satisfied every default NDepend code quality criteria, the code could still be inconsistent, non-maintainable, and otherwise not of high quality.  Something to remember about these metrics is that they are general, and may not apply accurately to all cases.  Prime examples are automatically generated methods (which NDepend attempts to an extent to exclude in default queries), and there are other methods which NDepend thinks complex which really aren’t – namely, methods which involve a large amount of symmetry (if, elseif, elseif, elseif, etc.) – which can be easily understood by humans, but not by NDepend which doesn’t note the symmetry.

A common metric dispute would be the number of lines of code per method.  Many developers I’ve spoke with, mostly in academia, profess that a method should fit on one screen of an IDE (so you can see the entire method without scrolling).  Obviously, this rule is relative to screen resolution and size.  If you can afford a larger monitor, you can get away with longer methods.  NDepend eliminates the monitor loophole by stating that any method longer than 30 lines should be refactored.  Personally, I think this is a fair number.  Most clean methods are under 30 lines of code, and of those that are over, a significant portion of them are complex, hard to follow, and may accomplish much more than just one task.

Conclusion

Implementing NDepend has given the TaskTracer team a clearer image of its codebase and insight towards what we should fix and look out for in the future.  The many uses of static analysis data will help TaskTracer developers adopt standard quality coding practices, which will improve consistency, maintainability, and reduce bugs in the future.