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.5 Be consistent

Changing the way things are done is a certain way to cause confusion in the reader, and could lead to serious error. When a style is chosen, it must be used consistently. Depending on the level of agreement that can be achieved within an organization, the scope of usage of the standards may vary significantly. At the very least, even if there are no standards, code in one function should be consistent. The result of total inconsistency can be very confusing, as the following example of inconsistent naming, bracing and parenthesizing illustrates:

if ( WndHt < WIN_MIN)
{
    ResetWin(WPtr );
    while( WndHt> Winht)
        {
        WinHt =gethwindow( pWin );
        if ( WinHt== ( winhite * WND_CORR )) {
            stepup (wdwhght );
            STEPUP( wndwh);
        }
        }
}

<----------------------------------------------->

The consistency principle applies to all elements of style, including naming, commenting, layout and usage. It should also be applied to the selection of standards. If, for example, one brace style is selected, then the same style should be used for both code blocks and declarations (including struct's, union's and enum's).

<--Prev page | Next page -->