Program Design Language (PDL)

1. Program Design Language (PDL) Slides by: Noppadon Kamolvilassatian Source: Code Complete by Steve McConnell, Chapter 4

2. Steps in Building a Routine

3. PDL Overview • PDL (Program Design Language) is for designing at a slightly higher level that the code itself. • Use English-like (or Thai-like) statements that precisely describe specific operations • Write PDL at the level of intent • Write PDL at a low enough level that generating code from it will be nearly automatic

4. Example of Bad PDL

5. Example of Good PDL

6. PDL Benefits • PDL makes reviews easier • PDL supports the idea of iterative refinement: architecture->interface & PDL->source code • PDL makes changes easier • PDL minimizes commenting effort • PDL will be turned into comments for source code • PDL is easier to maintain that other forms of design documentation

7. Design the Routine Example: ReadErrorMessage() Spec: RecordErrorMessage() takes an error code as an input argument and outputs an error message corresponding to the code. It’s responsible for handling invalid codes. If the program is operating interactively, RecordErrorMessage() prints the message to the user. If it’s operating in batch mode, RecordErrorMessage() logs the message to a message file. After outputting the message, RecordErrorMessage() returns a status variable indicating whether it succeeded or failed.

8. Design the Routine • Check the prerequisites • check if the job of the routine is well defined and fits into the architecture • Define the problem that the routine will solve • State the problem in enough detail • State the Input, Output, Internal data, Error handling • Name the routine • Use precise, unambiguous name (like ReadErrorMessage() ) • Avoid names with the words ‘Handle’, ‘Process’ or other vague words

9. Design the Routine • Decide how to test the routine • Think about testing cases, the method to use, etc. • Think about efficiency • In general, refining overall design helps a lot more. • Research the algorithms and data structures • Don’t “reinvent the wheel” • Write the PDL • Begin with the purpose of the routine, followed by the algorithm

10. Design the Routine • Think about the data • If data manipulation is the main purpose, think about it before the logic. • Check the PDL • Make sure you really understand PDL. Otherwise, how can you understand the code written from it? • Iterate • Try as many ideas as you can in PDL before start coding. • Refine until each PDL statement can be translated into one or a few lines of code

11. Turning PDL into Code • Write the routine declaration • Added the header comment • Turn the PDL into comments • Fill in the code below each comment.

12. Turning PDL into Code • Check the code informally • Clean up the leftovers • Repeat steps as needed • In some cases, you may need to move back to design. • Formally review the code • Until you are sure that you understand why the code works! • The main difference between hobbyists and professional programmers grows out of moving from superstition into understanding.

13. Example of a Header Comment

14. Example of PDL

15. Example of Expressing PDL Comments as Code

16. Example of Expressing PDL Comments as Code

17. Complete Routine

18. Complete Routine

19. Complete Routine