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.4 What should the standards contain?
The standards may contain some or all of:
-
A definition of the criteria used in selecting the standards.
-
A description of how the standards may be changed.
-
A summary of the standards, preferably in 'pocket book' and/or
'wall-chart' format.
-
For each standard:
-
A description of the standard.
-
A description why the standard should be
used.
-
Correct and incorrect examples of the
standard.
The language of the standards should reflect your
organization. Remember that the prime target is to get the standards into use.
Too many 'must's and 'shall's can cause a revolution in a company where the
programmers have any reasonable degree of autonomy. There should be a balance in
the text between treating the reader as a 'language lawyer', who knows every
nuance of the language, and a complete idiot, who must have every last detail
explained.
References for your standards may be found in
several places:
-
This book, of course, contains many relevant point. It
nevertheless does not claim to be either exhaustive not definitive.
-
Other books. The bibliography contains books which may help. C
books in particular often contain an implied style with explicit comments on
specific elements. The archetypal such book is, of course, Kernighan and
Ritchie's definitive 'The C Programming Language'.
-
In the compiler/linker manuals. The system(s) that you use may
require special consideration (e.g. functions that are to be dynamically loaded
into memory at different times may need to be defined in separate modules).
-
Electronic conferencing systems. If you have access to such a
system, you can either put out a call for ideas/opinions, or you can
alternatively sit back and watch other people argue (such as in 'comp.lang.c'
from the 'Usenet' conference).
-
The programmers in your company. Most programmers will happily
give you their pet ideas (but be careful not to give any assurances that all
such ideas will be incorporated). Programmers who have worked in other companies
or in other parts of the same company may be able to help. Programmers who went
to different colleges may have some notes on style.
-
In C programs. Just look at any code listing and you will find a
wealth of ideas for programming style. By examining the existing programs in
your company, you may find common styles which will be easier to implement as a
standard.
<--Prev page | Next page -->
|
