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.15 Utilize available tools

A number of software tools are available to help with the style elements of the coding task. The use of these may be standardized. Such tools can include:

Editors

Programmable editors, such as 'emacs', can be set up to automatically generate program constructs, comment blocks, etc. in your standard style, making conformance to standards easier. They can also be set up to search for common layout features.

Compilers

The features of the compiler may be fully used to give warnings of possible problems. Typically, flags may be set to give different levels of warning. It is usually best to set the maximum warning level (it is better to consciously ignore a warning than not to know about it). It is also worth comparing the capabilities of such features when choosing a compiler.

Search programs

By using a consistent layout, items such as function declarations may be simply listed with programs such as 'grep'. Ease of use with these programs may even drive some of the layout decisions.

Language checkers

Programs like 'lint' will take a fine-toothed comb over your programs, and complain long and loud about many details that the compiler will not comment about at all. When using these, it is a good idea to document which errors are to be checked for, and which must be dealt with.

Complexity checkers

Programs are available which will measure the complexity of your code. Measures such as those described by McCabe or Halstead give simple figures to indicate the complexity of code functions. Some programs will even draw maps to show graphically the knots in your functions!

'Pretty-printers'

'Pretty-printers' or 'beautifiers' (eg. 'cb', 'indent') will reformat the C program according to standard or selected layout standards.

There is an argument which suggests that people may have their own individual layout standards, and that when they wish to read programs, they simply pass the program through the pretty-printer. This argument is limited, as style is considerably more than just layout, and even this cannot wholly be determined by syntax. Where layout shows intent, a pretty-printer cannot read the mind of the author. Pretty printers cannot add comments, create meaningful names or change obscure use of C syntax. They also take time to use (and may not be available to the person in the future wanting to look at your code). It is also not very easy to use pretty-printers on hard-copy printouts, which is probably the first port of call of a maintainer, looking for a bug.

The only sensible use of pretty-printers is to bring the assorted layout of 'old' code up to a common standard.

Home-brewed programs

The programming process may be assisted by writing your own programs, for example to extract the function headers of public functions into documentation.

<--Prev page | Next page -->