Defining Programming Standards   
for Professional Programmers 
  

         

Home

Contents

1: Standards

2: Psychological Factors

3: General Principles

4: Commenting

5: Naming

6: Code Layout

7: File Layout

8: Language Usage

9: Data Usage

10: Programming Usage

11: Implementing Standards

A: Example Standard

B: References

C: Glossary

Syque

About

Share this page:

Google
C Style
syque.com
Web

 

 

Books and
more at:

USA:

In association with amazon.com

UK:

In Association with Amazon.co.uk

Canada:

In Association with amazon.ca

 

 

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.7 There's no one true style

There is no such thing as a 'correct' style. There are almost as many styles as there are programmers. Some are more sensible than others, but there is no one style that can be clearly agreed upon as being the best style to use.

In reading this book, you will almost certainly strongly disagree with some propositions. On the other hand, you will probably find yourself agreeing wholeheartedly with other points. It is worth keeping in mind that there is likely to be someone else reading the book who has diametrically opposite opinions to yours.

Some points may be argued logically and clearly, for example where it is about a point of portability, and some item of style simply will not work with some compilers. Some points are much easier to argue about (and often are!), such as the placing of braces or the use of case in naming.

But in the end, one style must be chosen. You have to say, "This is the style that we will use. We have argued over which one to use, and the consensus is that this is it". Doubters and dissenters may have to be persuaded or coerced, for although your style is not perfect, it has been chosen to be standard.

A maintenance note: If you happen to be changing a program that does not use your style, then the professional approach is to use the style that the program uses, rather than to use your normal style. Maintaining poor style is difficult enough - maintaining several styles at once is hell!

 

<--Prev page | Next page -->

 

 

 

  © Syque 1995-2006

Massive Content -- Maximum Speed