Program Design Language (PDL)

Slides by: Noppadon Kamolvilassatian

Source: Code Complete by Steve McConnell,
Chapter 4

1
Steps in Building a Routine

2
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

3
Example of Bad PDL

4
Example of Good PDL

5
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

6
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
t h e p r o g r a m i s o p e r a t i n g i n t e r a c t i v e l y,
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
w h e t h e r i t s u c c e e d e d o r f a i l e d.

7
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
8
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

9
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
10
Turning PDL into Code
 Write the routine declaration
 Added the header comment
 Turn the PDL into comments
 Fill in the code below each comment.

11
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.
12
Example of a Header Comment

13
Example of PDL

14
Example of Expressing PDL Comments
as Code

15
Example of Expressing PDL Comments
as Code

16
Complete Routine

17
Complete Routine

18
Complete Routine

19