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.8 A standard which isn't used, isn't a standard

In making decisions about which items to standardize, it should be remembered that for many points, there is either a de facto standard (typically set by Kernighan and Ritchie), or a limited set of common ways of doing any one thing (eg. layout of braces). The further from these norms that a proposed standard is, the less likely it is to get used and, more importantly, the less likely that the new reader is to understand what it means or agree with its usage.

If a 'standard' is sufficiently silly, picky or just plain unpopular, then it simply will not get used. And if it is not used, then it is not a standard. When looking through the rest of this book, and trying to select a set of standards, keep asking the question: "Will this actually get used?". If the answer is a definite no, then it is probably not worth adopting, even if is a worthy and significant point of style.

Setting up standards is more than just defining them - it also means persuading people to use them. The problems of implementing coding standards are discussed further in chapter 11.

<--Prev page | Next page -->