Choosing a Coding Standards Checker
Our selection criteria included product usability features, but not specific details (rule selection, rule execution, and scalability). We established these criteria from our experiences with previous coding standards checkers, feedback from project development teams, and product evaluations.
Ability to modify rules. Most coding standards checkers include preimplemented rules. Having built-in rules reduces the rule implementation effort. However, these rules usually do not fully match our coding style. Moreover, because most rules are implemented simply, false positives are common, making the results unreliable. We needed an easy way to customize the rules to exclude exceptional cases, add new rules, or modify the existing rules. Lint-like tools can check some coding standards items, but lack rule customization features. Though some checkers provide parameterization techniques for rule customization, more flexibility is required for modifying rules in detail.
Ability to report coding standards compliance at various levels. Many coding standards checkers support file-level reporting. However, for management purposes, package- and project-level reporting is desirable. For example, project managers often want to review coding standards violations by packages or by projects to identify trends and prioritize the correction of coding standards violations—especially when deadlines are approaching.
Ability to integrate with development environments. Many rule violations can be easily corrected. For instance, violations like "Use tabs instead of spaces to indent" can be corrected by simply replacing the spaces with tabs. In such situations, having a coding standards checker with direct access to the violation source (through tight integration with the development environment) significantly reduces the time required for correction.
Additionally, as a project evolves, it includes more files and more "include/directive" settings. If the checker does not run inside the IDE, the checker should create project files by importing or synchronizing with IDE project files, such as makefiles, dsp/dsw files, and so on. This saves time configuring the environment for running the checker.
Ability to make unified rules for C/C++. Our major programming languages, C and C++, have a similar structure—except that C++ has more features for object-oriented and generic programming. Maintaining two different rules for the common items in these languages would require extra resources.
Ability to recognize language variation. Compared to C, C++ has a short history. Compiler vendors produced their own C++ compilers before the ISO C/C++ was established and research shows that many C++ implementations do not yet perfectly support C++ ISO Standards (http://www.ddj.com/184405483). Since coding standards checkers usually parse the source code, the supported language variations are significant.
Ability to check unprecompiled header files. Some coding standards checkers lack direct checking for header files. Instead, violations in header files are indirectly reported by checking header file parts in the precompiled implementation files. In this case, violations related to preprocessor directives and comments in header files, which usually contain important information used by other developers, are ignored. Therefore, direct checking of header files is desired.
