Darrell Norton's Blog [MVP]

I don't use it in the manner you descirbed above although when I was first taught programming at high school that was how the teacher taught us. I think we did Nasi-Schniederman diagrams (it was over 10 years ago now :)

I sometimes use psuedocode when a junior developer asks me for help.

We'll work through the problem and sketch out the solution giving them suficient detail to go back and create the working code. So the idea is not to produce 100% working code on paper, I guess you could call it non-compilable VB.

I find sometimes getting them away from visual studio and making them describe the problem out loud and writing it down seems to help.

Ben

Using pseudo-code to prototype the detail of logic before writing code was in vogue during the 70s and 80s when writing specs was mandatory in order to control feature creep, spending on projects, and containing the schedule. Usually, a smaller, simpler language was used as the "pidgin language" in which the pseudo-code was written: sometimes it was Pascal or a Pascal-like toy language like XPL (described and available in Bill McKeeman's infamous book "A Compiler Generator").

Pseudo-code would completely describe the functionality (down to within functions, including function and variable names) in an "Internal Design Specification". Depending upon the company/organization and it's rigidity/laxness of software development method, the completeness of the pseudo-code and it's use during design reviews ("pseudo-code reviews") would be instrumental in guaranteeing that the coding process was a routine (and usually boring) process that would be as bug-free as possible.

In fact, some companies (like one I was in for a few years) even used the XPL compiler to "prove" the pseudo-code not only compiled, but to debug DURING the DESIGN process! (This was during the era when "program provability" was a very real discipline, which brought us the idea of the government's "Trusted Computing Base" certification scheme, in which the highest ranking of "A1" could only be given to a "computing system" of both hardware and software that was mathematically "provable".)

At that company, the resultant apps were actually the XPL load modules. Thus, this notion of writing complete pseudo-code during the design process completely eliminated the coding process, since the pseudo-code was the actual target code. (Yes, we wrote the code in order to prove we could write the code. Sort of recursive in nature, but it gave a level of provability that could not be achieved in any other manner.) An added advantage to this rigid development method was that the resultant IDS would be 3-5 times the page count of the actual code, which served to document the code to the anal point of absurdity...

Now back to the point: IDS's would contain not only pseudo-code, but complete English descriptions of how each section of code satisfied features that were enumerated in the "External Design Spec", and (dromroll please!) cross-references to the unit-test test-cases in the "Test Design Spec". (We even had coding standards of how to comment sections of code to refer to the unit-tests by test-case id number...which was text-mined to produce a table that xrefed unit-test ids to function and line # and vice versa.) Basically, by the time the IDS was finished and reviewed several times, the Test Engineers would have all the test-cases written and documented in their TDS.

Provability for most companies (even those not interested in the vaulted TCB Certification level of B2 or B3), meant 100% pass rate of all unit-tests. Coverage tools were written to ensure that the test harness completely tested all code.

Essentially, PPP and TDD are NOT new ideas; rather, they're enjoying a comeback. (Everything I mentioned above was in place everywhere I worked prior to 1980...) If it weren't for pseudo-code, then the tight binding between code functionality and unit-test test-cases wouldn't have been possible.

In summary, of the dozens of projects on which I worked where the above rigid development methods were employed, NONE failed (and most applications had near zero bugs even after a year or two). At companies that did NOT employ the above methods, there was a constant death march to try and reach a mythical "zero bugs" point (which we all know is NOT POSSIBLE!).

The problem with NOT using a "provability" development method (even one that's watered down), is that you always end up turning the old Apollo Mission motto "Failure is NOT an option!" into "Failure IS an option!". The whole rush to create software via discarding/ignoring useful techniques like PPP and TDD brought us the Dot-Bomb era due to the insanity of "web-week" schedules and that silly notion a 15 year-old with only 3 weeks of HTML experience can produce full-fledged bug-free apps.

To this day, I use PPP during white-boarding and code reviews, with a good pidgin language such as Eiffel, since Design-By-Contract language idioms can often help catch functional errors and produce more secure code.

I have used it in the past, but don't any more since (1) I use TDD which gives me many of the same benefits, and (2) I program in Python, which has been described as executable pseudo-code. If it is just as easy to write code directly as it is to write the pseudo-code then there is little benefit to adding an extra layer of work. Nowadays if I try to write pseudo-code it comes out as Python anyway 8^).

Even when not using Python I found that instead of writing a pseudo-code comment it is just as easy to write a function with a name based on the comment I was going to write, then create the function later. This results in code broken down into short functions with clear names.

Dave

Like many of the commenters, I've not found the process that helpful, preferring a single prose description of what a function is meant to do, and only documenting "oddities" within the function (if they really cannot be avoided, of course).

One technique I did find useful, though, was to generate low-level spec documentation by writing skeletal classes with Doxygen comments (at the time I was writing unmanaged C++, XML comments and NDoc would obviously do the trick for .NET code). In some cases then I did add (non-Doxygen) psuedocode comments that would give me some idea how the methods would be implemented, especially if the were simple wrappers or template methods.

Wow, great comments everyone! I'm learning tons here.

I used to rely on pseudocode heavily, but now, I ususally use it when I'm sketching out code for someone else to implement.

I do only occasionally if I'm having a hard time concentrating. Not sure about the exact method you describe, as I haven't gotten to that book in the pile yet.

For me it depends on two things:

1. How complex the logic is

2. If I'm giving it to someone else (as Brendan mentioned)

Other than that, I don't write pseudocode all that often anymore. I used to use it quite a bit in my more inexperienced days, but as time goes on, I rely less and less on it.

I can definitely see the benefits of what everyone is talking about.

I do notice that I use pseudocode (and comments in general) more heavily when I'm dealing in a "lesser" development environment, such as SQL Server Query Analyzer. Without the freedom to break up and structure my code as easily, I rely on comments and pseudocode to keep code readers informed about what I'm doing, and also because T-SQL can be harder to figure out what is going on than C# or VB.

I generally use a form of this, I basically comment out methods to get the steps needed and follow up with the actual code. I generally don't do many methods at the same time but break out by function.