How we change what others think, feel, believe and do

| Menu | Quick | Books | Share | Search | Settings |

C Style: Standards and Guidelines (contents)

CHAPTER 1 : Standards


CHAPTER 1 : Standards

1.1 Standards
1.2 Guidelines
1.3 What are standards for?
1.4 What are coding standards for?
1.5 Who are coding standards for?
1.6 Coding standards vs. programming standards
1.7 Using this book

1.8 Summary

<-- Prev page | Next page -->


1.4 What are coding standards for?

Translating the manufacturing reasons for standardization into factors for consideration in coding standards results in several clear reasons for standardization:


Productivity in the writing of code means saving time (not only in the original coding, but also in future support and maintenance), without incurring a penalty in quality. Thus it must be:

Toolable If available tools can be properly used, then this may reduce human effort on the program.

Portable Portable code is easy to translate to other software and hardware platforms. Non-standard code is likely to be non-portable too.

Reusable If a section of code can be re-used, then the entire time to write it is saved each time it is reused. Note, however, that the quality of the code is reused too. Any problems in the code will be multiplied by reuse.


The quality of the code lies in its conformance to specification (assuming, of course, that the specifications are correct). Thus it must be:

Testable Consistent and simple code results in good tests which are easy to write. Complex code requires complex tests which are often still incomplete.

Reliable Reliable code holds no surprises. It has few defects, and any problems are handled consistently and gracefully.


It must be possible for other programmers to maintain and use the code. Thus it must be:

Enhanceable To add new features to the code requires that it can be understood and has no tricky interfaces.

Fixable Fixable code is not only easy to understand, it also helps the maintainer by providing diagnostics to locate the problem area (error messages, core dumps, etc.).


To be able to do all of the above, the code must be understandable. This means that it must be:

Consistent The way things are done should be the same throughout the program. This applied to usage of programming constructs and to the layout of the code.

Communicable To understand code, it must be easy to read and to explain. To pass ownership of code to someone else (e.g. a maintenance programmer) it must be both explainable and self-explanatory.

Coding standards address all of the above points either directly, for example where they recommend portable usage, or indirectly, for example where use of them results in more reliable code.


<-- 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-
Massive Content -- Maximum Speed