syque.com

The Psychology of Quality and More

| Menu | Books | Share | Search | Settings |

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

 

 

Site Menu

| Home | Top | Settings |

Quality: | Quality Toolbook | Tools of the Trade | Improvement Encyclopedia | Quality Articles | Being Creative | Being Persuasive |

And: | C Style (Book) | Stories | Articles | Bookstore | My Photos | About | Contact |

Settings: | Computer layout | Mobile layout | Small font | Medium font | Large font | Translate |

 

You can buy books here

More Kindle books:

And the big
paperback book


Look inside

 

Please help and share:

 

| Home | Top | Menu |

© Changing Works 2002-2015
Massive Content -- Maximum Speed