9.4. Alternatives to the PPP

For my money, the PPP is the best method for creating classes and routines. Here are some different approaches recommended by other experts. You can use these approaches as alternatives or as supplements to the PPP.

Test-first development Test-first is a popular development style in which test cases are written prior to writing any code. This approach is described in more detail in "Test First or Test Last?" in Section 22.2. A good book on test-first programming is Kent Beck's Test-Driven Development: By Example (Beck 2003).

Refactoring Refactoring is a development approach in which you improve code through a series of semantic preserving transformations. Programmers use patterns of bad code or "smells" to identify sections of code that need to be improved. Chapter 24, "Refactoring," describes this approach in detail, and a good book on the topic is Martin Fowler's Refactoring: Improving the Design of Existing Code (Fowler 1999).

Design by contract Design by contract is a development approach in which each routine is considered to have preconditions and postconditions. This approach is described in "Use assertions to document and verify preconditions and postconditions" in Section 8.2. The best source of information on design by contract is Bertrand Meyers's Object-Oriented Software Construction (Meyer 1997).

Hacking? Some programmers try to hack their way toward working code rather than using a systematic approach like the PPP. If you've ever found that you've coded yourself into a corner in a routine and have to start over, that's an indication that the PPP might work better. If you find yourself losing your train of thought in the middle of coding a routine, that's another indication that the PPP would be beneficial. Have you ever simply forgotten to write part of a class or part of routine? That hardly ever happens if you're using the PPP. If you find yourself staring at the computer screen not knowing where to start, that's a surefire sign that the PPP would make your programming life easier.

cc2e.com/0943

Cross-Reference

The point of this list is to check whether you followed a good set of steps to create a routine. For a checklist that focuses on the quality of the routine itself, see the "High-Quality Routines" checklist in Chapter 7, page 185.

Checklist: The Pseudocode Programming Process

• Have you checked that the prerequisites have been satisfied?

• Have you defined the problem that the class will solve?

• Is the high-level design clear enough to give the class and each of its routines a good name?

• Have you thought about how to test the class and each of its routines?

• Have you thought about efficiency mainly in terms of stable interfaces and readable implementations or mainly in terms of meeting resource and speed budgets?

• Have you checked the standard libraries and other code libraries for applicable routines or components?

• Have you checked reference books for helpful algorithms?

• Have you designed each routine by using detailed pseudocode?

• Have you mentally checked the pseudocode? Is it easy to understand?

• Have you paid attention to warnings that would send you back to design (use of global data, operations that seem better suited to another class or another routine, and so on)?

• Did you translate the pseudocode to code accurately?

• Did you apply the PPP recursively, breaking routines into smaller routines when needed?

• Did you document assumptions as you made them?

• Did you remove comments that turned out to be redundant?

• Have you chosen the best of several iterations, rather than merely stopping after your first iteration?

• Do you thoroughly understand your code? Is it easy to understand?