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.13 Keep project standards

In an organization where there are multiple independent project teams, each team may be using standards which are not written down in any wider set of standards. These will include items such as selections from optional standards (eg. bracing style) and project specific items, such as standard abbreviations and prefixes (eg. 'Kbd' for keyboard).

It is important to document these clearly and to keep these alongside the 'standard' standards. A copy should be kept (a) in a central repository, alongside all other project data, and (b) on every programmer's desk.

 

<--Prev page | Next page -->

 

 

  © Syque 1995-2013

Massive Content -- Maximum Speed