The Art of Pseudocode

Our project at work frequently has tasks that require software design. We are required to document our design at a high and low level in different design documents. I frequently contribute to this effort. My normal instinct when writing an algorithm in pseudocode is to use a mixture of English and PL/SQL code. This follows the precedent made by the original designers of our system. The chief architect was a PL/SQL developer. So naturally he expressed and documented his designs in PL/SQL. I follow that trend to this day.

Right now I am taking a Java programming course at the local community college. My Java book has some alternate methods to writing pseudocode. They seem fine. Often they include Java specific keywords. Since I am in the middle of learning the Java programming language, this pseudocode is quite easy to follow.

My instructor has some other ideas about how pseudocode should look. He concedes that there is no official standard for pseudocode format. However he believes there is an unofficial industry standard. One characteristic of this standard is that each line of pseudocode should begin with a verb.

Now I am usually in favor of standards. However standards need to be written down and agreed upon. Otherwise there is no objective standard. My own opinion about pseudocode is that it should clearly communicate algorithms and design. If it accomplishes that task, I don’t care what the format of the pseudocode is. For my class I will adhere to any format my instructor requires. But out here in the real world, you use the tools and formats that get the job done.

If my instructor were to read my blog, he would give the old “minus 2 points Maintenance Man” in jest. Therefore I will not give him the URL of my blog until I have long since aced his class.