Like this article? We recommend

Like this article? We recommend

Enforcing Coding Standards

Developing and documenting coding standards is just the first step toward
improving the quality and efficiency of a project/organization. Once the coding
standards have been developed, they must be revised regularly and enforced
strictly.

TIP

To aid acceptance of coding standards, involve all developers on your team in
the process of creating/adopting the coding standards, and encourage
feedback.

Before any piece of code is developed, clear high-level and detailed designs
should exist. The high-level design should give an overview of the
technical/applications architecture, workflows, and database structure. The
detailed design should specify the filename of the code along with inputs and
outputs, and provide a short overview of the processing carried out by each
method/function within that file. The design should be reviewed by someone who
has appropriate business and technical knowledge.

Every piece of codescript, SQL, module/classshould be reviewed in
a peer code review or code walkthrough process. This simple step often helps to
prevent a great number of defects. The peer review process consists of a check
for the following possible problems:

After a piece of source code has passed the peer review, it can be placed in
the main shared source code repository for the current release being developed.
(Until this point, it's likely that the source code would reside in a
private source code control area specific to the developer.) Before the code is
checked into this repository, however, the "source code manager"
should review the code. The source code manager should have sole control over
the main source code repository (which may have a number of source code trees
for development, test, live, and any previous versions/releases). Developers
shouldn't be able to check in code without going through this individual.
The source code manager should check for the following:

Filename naming conventions

Package/directory structure

Configuration files/registry keys needed

Database changes required by the code

Changes made since last time checked in:

Commented

Logged in the change management log/defect log

Appropriate labeling/version

Unit tested

When all the code for a particular release has been through the above two
reviews, the code is ready for system test and then user acceptance test. These
tests should include testing and QA procedures to ensure that the
look-and-feel/GUI standards for the project have been followed and are
consistent across the system. It should also include checks to ensure that the
system works consistently across different environments on which it needs to
runfor example, on Windows and on UNIX, or perhaps on different PDAs and
cell phones.

Tools are available on the market to check code against coding standards to
help speed the code review/QA process. Though I can't recommend any specific
code analyzer, following are a couple of examples: