Click here to Skip to main content
Click here to Skip to main content

Design and Document your Code using PDL (Programming Design Language)

By , 26 Jun 2010
 

Introduction

Many of us underestimate the importance of proper code documentation through comments. Comments, when used correctly, can greatly increase the maintainability of your functions and routines, especially if there is any chance that another developer will ever need to look at your code. It's hard enough for you to remember what your intentions were for a routine you wrote 5 years ago. Imagine what it's like for someone that has no clue what you meant to do in the first place.

Background

While reading "Code Complete" (every developer, regardless of skill level, age, or programming language should own this book), I discovered a method used to comment your routines that provides so much more than just code comments.

Using the Code

This method is called PDL (Programming Design Language). The basic idea behind PDL is that you write all of the comments for your method before writing any code. Once the comments are finished, you then fill in the blanks with the implementation.

Here is an example:

Public Function CanUserDrink(ByVal Age As Integer, _
	ByVal HasLicense As Boolean) As Boolean 
    'If the user is of the legal drinking age  
    'If the user has a drivers license 
    'Return success to the caller 
    'Otherwise the user does not have a drivers license 
    'Return Failure to the caller 
    'Otherwise the user is too young 
    'Return Failure to the caller 
End Function 

Public Function CanUserDrink(ByVal Age As Integer, _
	ByVal HasLicense As Boolean) As Boolean 
    'If the user is of the legal drinking age
    If Age > 21 Then 
        'If the user has a drivers license 
        If HasLicense Then 
            'Return success to the caller 
            Return True 
        'Otherwise the user does not have a drivers license 
         Else 
            'Return Failure to the caller 
            Return False  
        End If  
    'Otherwise the user is too young 
    Else  
        'Return Failure to the caller 
        Return False  
    End If 
End Function

A few things to note here:

  • All of the comments are formatted logically (indentation)
  • When using this method, you write the comments first in a high level format (plain English)
  • This allows you to design the routine at a high level of abstraction
  • The requirements are in English so the routine is designed such that it can be ported to any language very easily
  • All of the thinking work is done up front
  • All that's left is to fill in the code under each comment
  • The comments written in English explain exactly what you need, so implementation is a breeze
  • Since comments are written first, you can be rest assured that all of your methods will be well documented

If another developer is reading through your code, he can simply read your high level comments until he finds the code he needs.

Points of Interest

So as you can see, using PDL has several advantages:

  • Assures code is always documented
  • Allows for high level design of routine that does not rely on a specific programming language implementation (remember the comments are plain English)
  • Once the comments are complete, coding is a snap because the logic has already been documented in plain English in the comments.

I hope you find PDL as beneficial to learn as I have. Don't forget to buy Code Complete!

Until next time.

History

  • 27th June, 2010: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

bjames02
Software Developer bytepushers.com
United States United States
Member
I'm a 28 year old software engineer from Tennessee. I've been programming since I was 13 years old. I'm fortunate enough to be able to do what I love for a living.
 
VB.NET, ASP.NET, C#, assembly, HTML, JavaScript, AJAX
 
I'm MCP, MCAD, MCSD.NET certified.
 
follow me on twitter
 
http://www.twitter.com/budbjames

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralMy vote of 2memberswampmonster14 Feb '11 - 10:46 
This kind of comments are the comment-equivalent of "undocumentation".
 
IMO, comments that state what the followind 1-2 lines obviously do are just distracting - noise.
To me, they make programs harder to read/navigate.
 
It's a great way to show absolute beginners what's going on, e.g. in a tutorial for some programming-language, but in actual production code... hm.
 
Stuff that's not obvious should be explained with comments. Also if it's obvious what the code does, but not why, document the why.
However stuff like...
 
// Print the username
printer.PrintLine(user.name);
 
Use good names for your variables, functions and classes, and you don't need that kind of comments.
 
Also more comments means more chances of someone forgetting to update them as the code is changed.
 
Take a look at the CanUserDrink example again. Now consider the following alternative:
 
Public Function CanUserDrink(ByVal Age As Integer, ByVal HasLicense As Boolean) As Boolean
' User must be old enough and have some kind of ID that proves it.
' Since we just care about the US, we hard-code 21 as the legal age for drinking for now.
' TODO: move age limit to configuration file.
Return (Age >= 21) And HasLicense
End Function
 
Now that's 6 lines vs. 19, and those 6 lines actually contain (much) more useful information.
GeneralMy vote of 5memberslnsimha19 Jul '10 - 3:22 
Excellent
GeneralRe: My vote of 5memberbuddy.james1 Jan '11 - 22:26 
I'm glad you enjoyed it.
 
http://www.twitter.com/budbjames
http://www.bytepushers.com/blog
GeneralGood IdeamemberMaher Elsayed12 Jul '10 - 10:47 
I'm using this way and it's very efficient for helping you to arrange your logics.
GeneralRe: Good Ideamemberbuddy.james1 Jan '11 - 22:29 
Yes the beauty is that in writing your comments first, you are thinking in terms of human language and not syntax.
 
This allows you to design at a higher abstraction. This also allows you to write portable code because since you design the code around human language, you aren't limited to data types or functions of a specific language.
 
Thanks for reading.
 
http://www.twitter.com/budbjames
http://www.bytepushers.com/blog
GeneralMy vote of 3memberAbhinav S9 Jul '10 - 7:33 
Could this have been a tip / trick instead?
GeneralMy vote of 4memberTomS456 Jul '10 - 15:53 
Good concept, but creates unneeded comments
GeneralDesign and Document ....memberTomS456 Jul '10 - 15:52 
Sorry, mate. But this concept has been around for all the 40 years I've been pounding out code. It's called "pseudocode" - english, or whatever your native tongue is, statements that define the flow of the program. I've worked on teams that produced 1000's of lines of pseudocode that, when coded and cleanly compiled, had very few bugs. We used the pseudocode to do another "old" concept, the structured walkthrough, which often identified errors for correction before the first line of code was actually written.
I taught programming principles for over 15 years and always introduced these concepts to my students. But it is nice to see these tried and true techniques taught even if the names have changed.
Thanks for taking the time to write this article. Just remember, the statement I = I + 1 DOESN'T need a comment. Smile | :) Smile | :)
 
Take care,
Tom (no longer 45!)
GeneralRe: Design and Document ....memberbjames026 Jul '10 - 16:11 
TomS45 wrote:
Sorry, mate. But this concept has been around for all the 40 years I've been pounding out code. It's called "pseudocode" - english, or whatever your native tongue is, statements that define the flow of the program. I've worked on teams that produced 1000's of lines of pseudocode that, when coded and cleanly compiled, had very few bugs. We used the pseudocode to do another "old" concept, the structured walkthrough, which often identified errors for correction before the first line of code was actually written.
I taught programming principles for over 15 years and always introduced these concepts to my students. But it is nice to see these tried and true techniques taught even if the names have changed.
Thanks for taking the time to write this article. Just remember, the statement I = I + 1 DOESN'T need a comment.

 
Thanks for the feedback.
 
I picked up the idea from the great book "Code Complete" (which should be on every developers bookshelf).
 
I was suprised at all of the negative comments regarding this strategy.
 
Thanks again for the positive feedback..
 
I will update the article to mention pseudocode.
 
Thanks again.
GeneralMy vote of 5memberboundbystars5 Jul '10 - 17:53 
Great article describing PDL since I am just starting out I find this to be immensely beneficial. Besides how can Code Complete be wrong??

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web04 | 2.6.130523.1 | Last Updated 27 Jun 2010
Article Copyright 2010 by bjames02
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid