How Not To Write a Computer Program
Jason Lander
| Revision History | ||
|---|---|---|
| Revision $Revision: 1.33 $ | $Date: 2004/02/03 16:56:27 $ | |
- Table of Contents
- 1. The Art of Computer Programming
- 2. Making yourself understood
- 2.1. Idioms
- 2.2. Coding Styles
- 2.3. The Importance of White space
- 2.4. Comments
- 2.5. Variables
- 2.6. Constants
- 2.7. Conditionals a.k.a. IF statements
- 2.8. Avoiding IFs - lookup tables
- 2.9. Other types of conditionals
- 2.10. Loops
- 2.11. Subroutines and functions
- 2.12. When to use subroutines and functions
- 2.13. How to use subroutines and functions
- 2.14. Structures - Keeping your data neat and tidy
- 2.15. Objects - a step beyond structures
- 2.16. Pointers and References
- 2.17. Code Generation - getting the computer to do the hard work
- 2.18. Functional programming
- 3. Coding for Safely
- 3.1. Defensive Programming
- 3.2. Assertions
- 3.3. Exceptions
- 3.4. Leaving a trail
- 4. The Right Tools for the Job
- A. Acknowledgments
1. The Art of Computer Programming
There are some people who consider Computer Programming to be an Art which, in the right hands, it is. [1]
However, like art, it is possible to talk complete bollocks about computer programming and still be taken seriously. Worse, still, it is possible to mistake incomprehensible gobbledegook for genius and pick up all sorts of bad habits.
Most people - outside some of the more formal bits computer science degrees - learn to program from the code of others. If you are presented with 50000 lines of FORTRAN 77, it is not always clear what is good practice, what is bad practice, and what was copied from a punched card in early 1967.
This course is will not to teach you how to program. It may teach you is how to learn how to program by recognising what is right and what could be done better. Most of the ideas are independent of the computer language you are using.
Though the ideas in this course have come from many sources, many of the rules below are similar to those to be found in `The Practice of Programming' by Brian Kernighan and Rob Pike.
Those of you with a sensitive disposition are warned that there will be examples of good and bad programming practice in a number of languages. These are based on real code although some variable names have been changed to protect the innocent.
 | Beware of author bias |
|---|---|
This particular author likes Unix-like operating systems, Perl and scripting languages and object-oriented coding; tolerates C and Pascal in their place; can recognise Lisp on a good day; dislikes BASIC and thinks most existing FORTRAN 77 code should be buried at sea. You may disagree. If you do, feel free to write your own programming course. |
1.1. Talking to Computer Programmers
Computer programmers don't just communicate in acronyms. Programming has a terminology all of its own.
Computer code can be elegant or ugly. Only one of these is a complement.
It can be written using in a structured, an object-oriented or a functional style. It can make use of abstraction and encapsulation.
All these terms refer to things you do to make your code understandable by other programmers.