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.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 -->

 

 

  © Syque 1995-2010

Massive Content -- Maximum Speed