Simple Rules for Writing Quality Programs

1
Simple Rules for Writing Quality Programs

• Dale Courte
• University of Dayton

2
The Rules

• Start high-level.
• Cover the bases.
• shorter code reliable code
• fewer variables simpler solution
• Readability matters!
• Track down problems.
• Be skeptical.
• Look somewhere else.
• Your code is not sacred.
• Help Yourself

3
Start high-level.

• I cannot stress this too much. The first step in
  creating a solution does not involve writing
  code, or even any particular programming
  language. Start by jotting down a logical, very
  high-level algorithm. Follow this by adding
  detail to each of the steps, making sure those
  steps adequately address the problem at hand.
  Repeat this process until your solution is
  complete. Only then should you translate the
  solution to code.

4
Cover the bases.

• Make sure your algorithm is complete
• Requirements are met.
• including required error checking
• Boundary conditions are covered.
• empty/full data structures
• Code has been written.
• Testing has been completed.
• Every line of code has been executed.

5
shorter code reliable code

• Reliability - Every line of code you write could
  contain an error.
• Modularization - If a function you are writing
  becomes long enough that it is nontrivial to
  follow, break it down into manageable parts.
• An emphasis should be placed on keeping functions
  to a reasonable size.
• For this class, functions should not exceed one
  printed page in length.

6
fewer variables simpler solution

• Keeps logic clear, thus improving readability.
• Simplifies debugging.
• Helps reduce code size.

7
Readability matters!

• Includes
• descriptive naming
• clear logic
• consistent, standard formatting conventions
• comments
• Aids in debugging.
• Therefore reduces development time.

8
Track down problems.

• Dont blindly look for problems with your code.
  Track down errors methodically by checking
  intermediate results and verifying correctness.
• Use the computers power to your advantage!
• Tools
• output statements
• debuggers
• your brain (more powerful than a Pentium chip)

9
Be skeptical. (surprise!)

• Never assume code is correct
• especially your own
• certainly not mine
• not even production code (though dont use this
  as an excuse)
• Verification should be realized through testing.

10
Look somewhere else.

• Programmers have a tendency to think they know
  where a bug is in their code, when they really do
  not.
• If you find yourself spending a long period of
  time trying to find an error in a certain part of
  your program, broaden your focus to include other
  code that may be interacting with the code you
  have been focusing on.

11
Your code is not sacred.

• Sometimes code is just bad, and needs to be
  abandoned. Learn from your mistakes and move on.
• If you cant verify to yourself that
  malfunctioning code you have written is basically
  correct, dont hesitate to start over.
• Dont hesitate to go back to the high-level and
  redesign your solution.

12
Help Yourself

• The best students always seek ways to enhance
  their programming skills.
• Use additional resources.
• Other textbooks
• Magazines
• Web sites
• Practice, practice, practice!
• If you think the only programs you should be
  writing are the ones required for class, you
  should think again.