Rules for Good Program Design

If you are doing it twice, you are doing it wrong. Every piece of code should be designed only once. When setting to a new project, look for places to reuse your previous code. Allow old code to be modified to serve multiple purposes. As you work in any language, you should be building a large toolbox of subroutines that you can bring to bear on each new task.

Borrow code. When able, pick a programming language that is popular, so you can go download code that others have already created. Check around before you commit hours to writing code that someone else probably already wrote.

Make the computer do the work for you. Work to make any repetitive task into an automated one. Some tasks will actually take longer to accomplish when not done manually, but over time you will recoup those lost minutes when performing similar tasks.

Find short cuts. If you expect that you will type the same command over and over, make an alias for it that is one or two characters long. Use an editor that allow easy insertion of long variable and command names. Fewer keystrokes, even for fast typists, can save a lot of time.

Make code legible. Make variable names and procedure names long and clear. Usually variables should be nouns, procedures should be verbs, and procedures that return a value of importance should be nouns. This is a critical part of good internal documentation. The time saved in making short variable and procedure names will be lost many times over when trying to read the code later. Add comments that say why you are doing what you are doing, and make sure that your programs are clear enough about how you are doing it.

Find elegant solutions. Perhaps the hardest part of good programming is creating abstract data structures and programs that can handle any problem that is likely to be presented. Code that has exceptions for unusual requests are difficult to maintain and fail to scale well when those unusual requests become common tasks.

Test. Always test out changed code in many different situations. Consider how a change might affect other programs. Make all your tests automated, or you will not want to run them all the time.

There is no good writing, only good rewriting. Read over your code frequently to see how it can be improved. After a project has matured, a full rewrite will often sweep out all old bugs and accurately capture the evolved program requirements. Get other good programmers to read your code and offer suggestion. If you would be embarrassed to have your work critiqued, get busy rewriting it.