Like this article? We recommend
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:
Design defects/logic errors
Nonconformance to coding standards/GUI standards
Commenting/layout/legibility
Conditions that should be tested for in unit tests
Anything else that might improve code performance, efficiency, complexity, etc.
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:
-
Analyser for Java from Teamstudio
-
Programming Research offers code analyzers for C, Fortran, Java, and C++.