Channels ▼


Code Quality Improvement

Source Code Accompanies This Article. Download It Now.

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 ( 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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.