Defining Programming Standards   
for Professional Programmers 
  

         

Home

Contents

1: Standards

2: Psychological Factors

3: General Principles

4: Commenting

5: Naming

6: Code Layout

7: File Layout

8: Language Usage

9: Data Usage

10: Programming Usage

11: Implementing Standards

A: Example Standard

B: References

C: Glossary

Syque

About

Share this page:

Google
C Style
syque.com
Web

 

 

Books and
more at:

USA:

In association with amazon.com

UK:

In Association with Amazon.co.uk

Canada:

In Association with amazon.ca

 

 

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.7  Keeping the standards alive

You can not be expected to get it completely right first time, so you must make provision for how the standards are to be changed.

There should be a review several months after the first formal introduction of the standards (probably at the end of the pilot). After that, the standards may be reviewed at an agreed-upon period (typically yearly) or under special circumstances otherwise.

Beware of people using reviews to commit acts of sabotage, trying to 'bring back the good old days' or to re-implement their favorite variation. This is unlikely, but you may still find the odd 'real programmer' skulking in the cupboard.

Old standards and guidelines should not be thrown away all together, but they should be removed from public view. Put them in an archive, put the archive in the drawer, and hope that you don't have to take it out again (if you do, you'll be glad you kept them).

 

 

  © Syque 1995-2006

Massive Content -- Maximum Speed