The Psychology of Quality and More

C Style: Standards and Guidelines (contents)

CHAPTER 3 : General Principles

PART 1 : BASICS

CHAPTER 3 : General Principles

3.1 Keywords

3.2 Think of the reader

3.3 Keep it simple

3.4 Be explicit

3.5 Be consistent

3.6 Minimize scope

3.7 There's no one true style

3.8 A standard which isn't used, isn't a standard

3.9 Distinguish between standards and guidelines

3.10 Standards don't guarantee good coding

3.11 Decide on your portability quotient

3.12 Standards are a function of their audience

3.13 Keep project standards

3.14 Use standard libraries

3.15 Utilize available tools

3.16 Summary

<--Prev page | Next page -->

3.9 Distinguish between standards and guidelines

It is necessary to slavishly follow some standards, such as those which ensure portability. Other standards, depending upon how you define them, may be more flexible. Thus the wording you use is important. "Don't" means never; "Avoid" means mostly never. Generally, reasons for going against standards should be negative. That is, you should only decide not to use a standard because, "Something bad will happen if I follow the standard," rather than, "Something good will happen if I don't follow the standard." Using this rule should help to prevent tricky code.

<--Prev page | Next page -->