Code Quality Improvement

Lessons Learned

Until recently, our checking involved only the QA team checking coding standards compliance at the project level. This was effective for tracking defect trends and maintaining the rule set. However, there were several drawbacks.

First, the reported violation sources do not always match the code in the development environment. Developers don't usually work on a centralized source-code repository; they write and modify code in a private area, then copy or check-in the source code to the centralized repository. If the development source code differs from the code that QA is testing, it can be difficult for developers to identify and repair the source of reported violations.

Second, developers prefer to immediately verify that a violation correction has eliminated the problem.

For these reasons, we decided to have the coding standards checker run by developers as well as the QA team.

Developers who do not carefully follow standards may produce code with many violations, and are often reluctant to correct the violations. This is especially problematic with violations from identifier- or design-related rules, which are difficult to correct in later development phases because making such corrections can have a large, project-wide impact. We recommend checking coding standards conformance from the early coding phase so that the violated code is corrected before it is propagated out of the module.

One reason why the coding standards checking effort with our previous tool failed was the lack of rule maintenance at the organization level.

After the initial rule set is established, rules should be customized continuously because some rules might not apply to particular projects and development style might vary across development domains. A rule set should be maintained throughout each project's operations as the project constraints evolve.

Automatic coding standards checking should complement code reviews. In our development process, code review is mandatory because it effectively catches developers' logical errors and mistakes. However, developers nevertheless skip code reviews due to schedule constraints. Our experiences and research show that some developers are easily distracted by style issues and focus on them during code reviews (D. Kelly and T. Shepard, "Qualitative Observations from Software Code Inspection Experiments"; CASCON, 2002). Consequently, some developers view the code review process as being time-consuming with little benefit, and then skip it. This can be prevented by removing coding standards violations with automatic coding standards checking before the review, which allows the review to focus on finding logical and serious errors. Moreover, because automatic checking covers only about 50 percent of the items in our coding standards (some items are complicated to implement with an automated tool), code reviews are needed to check the remaining items.

Conclusion

We have applied the checker to several projects in our organization and achieved significant code-quality improvements in each case. We plan to apply it to additional projects and analyze the effects on code quality.