The Psychology of Quality and More

C Style: Standards and Guidelines (contents)

CHAPTER 11 : Implementing Standards

PART 5 : IMPLEMENTATION

CHAPTER 11 : Implementing Standards
11.1 Raising awareness of the need for standards
11.2 'Disadvantages' of coding standards
11.3 Getting the standards defined
11.4 What should the standards contain?
11.5 Getting the standards into use
11.6 Prove the value
11.7 Keeping the standards alive
11.8 Making sure the standards are used
11.9 Summary

<--Prev page | Next page -->

11.5  Getting the standards into use

Rather than the 'big bang' approach of demanding that everyone starts using them at the same time, it is probably better to start with the standards being used on a single project. It is also better if this is a new project, rather than an enhancement project where code has already been written. The project team should be well represented on the definition committee, and they should all be allowed to have a say during the review stage (get ownership!).

Tools to assist in the use of the standards are a good idea. Configurable editors, such as 'emacs' may have their 'C-mode' adjusted to provide the correct constructs, and pretty-printers, such as 'indent' may be used to revise existing code (see 3.15).

Make sure that the documentation is usable and not too daunting. Provide quick-reference guides, wall charts, etc. Set up short training sessions and workshops. Run discussion groups with users fielding questions to the task force panel (by now, they should be able to answer all criticisms).

It is arguable whether the standards should be imposed upon existing projects. A good guideline is to consider the amount of code which has already been written within the project. If most of the programming effort is in changing the existing code, and especially if there is already some form (defined or otherwise) of standards, then imposing the new standards is not really a good idea.

There is significant benefit to be gained if everyone in the organization is using the same standards, and all code is written to these standards. However, if this really is not possible, then the best compromise must be reached. The fundamental rule is 'Half a loaf is better than no bread'. Limited standards are better than no standards. If you really are unable to establish your standards, then modify them, or permit individual project teams to modify them, until they are acceptable. If projects change any existing standard or adopt any new standard, then the change should be recorded and the standards updated at the next review.

<--Prev page | Next page -->