Pseudocode or Code?

When pair programming I find pseudocode to be helpful sometimes. Our pseudocode is a reduced version of the code. In the end the pseudocode turns into real code (rather than description). So our code would look like:

get objectslist
foreach object
if object is somethin
do this
else
do that
end foreach

This is way faster to type out when your discussing something with a colleague. Once you have agreed on the design, one programmer can flesh out all the variables etc. without keeping the waiting colleague involved in all the boring stuff. So yes, I actually do you use pseudocode when the going gets complicated.

Actually, I tend to code that way too (never read CC). My one difference is that the last step, once everything is working, is to delete the pseudocode comments and put in proper comments.

It really depends on the complexity of the problem and how comfortable you are with the tools needed to solve it. If you struggle to read programming languages to begin with (e.g. if you are a beginner) then using psuedocode in design offers an obvious advantage. You can separate the solving of the problem from the writing of the code.

Its easy to forget just how hard it is for others to write code when you have been doing it for so many years that it flows naturally, just like writing in your native language.

In the work environment I would hope this would be the exception rather than the case… but then again, there is a ton of bad software out there.

I read the first version of CC many years ago and tried the PPP. I still use it today, although in probably a more abbreviated form that Steve McConnell suggests. However, I do find that once I start jotting down the comments on what to do, I have an easy time filling in the blanks. Also, just giving an extra minute of thought on the function I’m writing will often lead to a bit of design or refactoring that I might not have done had I just plunged into the coding. PPP is something that you have to try for a few days and see if you think it results in better code. Only then should you dismiss it.

I’m firmly in the pseudocode sucks ranks. Let me digress a bit…

Have you ever written pseudo-math? At the basic arithmetic level, it works. You use it to teach children, to make arithmetic (and, therefore, mathematics – supposedly) real to them, by relating it to things we can touch and handle (like OO, I suppose :).

Unfortunately, that ceases to be either practical OR helpful very quickly when you leave arithmetic.

It’s important to note that mathematics as written today did not come to be because of an external constraint. No, the mathematicians could have chosen anything to represent what they write, and, as a matter of fact, the notation has changed through-out history and is still changing today. Calculus, as written by Newton, bears no resemblance to what you get taught today.

So, if there were no external constraints to how the mathematicians write their stuff, why do they chose a notation so un-natural-language-like? It was NOT because they needed to exchange knowledge. It’s because natural languages are awfully inadequate to this purpose.

So, digression finished. I’m sure all of you got the point, but I’ll conclude with a statement I have made in this very blog many times, and which always generate a backlash. Code is Math.

Using UML to design and comments to comment.

Only script kiddies who don’t do real programming forget comments.

YOu might think your code is clear. But 4 years later when someone has to look at the code again, maybe the language has undergone changes, or even the next programmer just doesn’t understand your pseudoclear code.

Work at bigger firms, you even are forced to do some level of planning, not just doing write once, trash it code

I read the first version of CC many years ago and tried the PPP. I still use it today, although in probably a more abbreviated form that Steve McConnell suggests. However, I do find that once I start jotting down the comments on what to do, I have an easy time filling in the blanks. Also, just giving an extra minute of thought on the function I’m writing will often lead to a bit of design or refactoring that I might not have done had I just plunged into the coding. PPP is something that you have to try for a few days and see if you think it results in better code. Only then should you dismiss it.

Brian you said So, if it took 6 lines of code to look up the error message, then that one line comment would allow someone to essentially skim over the next 6 lines of code (unless if they are looking for a bug that exists in that block).

In this case I would do without the comment and create a 6 line method called lookUpErrorMessage(params…). Then not only is the code self commenting I could also use this method anywhere else I needed to look up an error message.

I hate pseudocode.
I prefer to actually write code.

At my job, the analysts have that bad habit of writing pseudocode instead of an analysis. Then, when you program, everything has already been thought for you (even function names,…), and you either have to try to understand what it’s supposed to do, or just follow it blindly.

Not mentionning that everytime the program change, you have to change the document.

We have programmers that dont really program, they just follow pseudocode.

And when they try to explain to the client what the program’s supposed to do, people who never programmed have to try to understand pseudocode!

We used pseudocode almost exclusively in my Algorithms class this spring. It seemed like a nice idea, but the problem we ran into is a professor with a very specific, very detailed idea of what pseudocode was. It was a defined language in her mind, which really hurt things. Still, I like the idea of developing pseudocode into comments…still seems to be a real problem with some people, adding little comments in there…:smiley:

Honestly, I think the most important part about pseudo code is that it is language agnostic. I don’t recommend writing pseudo code for everything, because it is overkill for solving simple problems.

In general though it is great, pseudo code allows your to focus on the problem, not the implementation.I think that is the most important advantage it gives you when trying to solve difficult problems.

It’s a personal preference, but it’s one you Agile nuts seem predisposed against.

I often write pseudocode when creating a new method. It helps me get my thoughts straight before writing real code. This is especially useful when I know I will be using API objects I’m not that familiar with. I can get the flow and logic down smoothly without having to interrupt myself finding the exact methods I need to call on the unfamiliar objects.

I don’t generally use that pseudocode as comments, though, as I agree the code should generally be readable enough not to need such detailed comments.

He Jeff

thank x for another great article , but don’t u think Pseudo code can help programmers for e.g junior programmers to understand the Requirement more as they write the requirement themselved in the form of Pseudo code then they will understand the requirement more as Pseudo code can reinforce the requirement in their mind

Nope. I rarely need pseudocode for the simplistic events of our web application. It basically breaks down to request data, access the database, format data for display, display the data. In the rare occasions where more complicated processing is required I might use a post-it note to jot down some thoughts on the process, but I would never write it out in plain English because that seems like a waste of time.

I agree that comments should describe why/how the code works, not describe what it is doing step by step.

Most things, I just write the code, but sometimes I have found it helpful to write out the process as pseudocode comments and slowly convert it to code. This helps for keeping things named well and removes the useless comments in the process.

Do you write pseudocode before writing code?

basically NEVER. for the same reasons as you cited.

i’ve shared your view on that chapter in code complete.

Jeff, I think you really hit on something when you wrote I find it easier to think about code in code.

Programming languages are just languages, the same as French or Japanese. Just as with human languages, no one is going to write a masterwork (novel, essay, whatever) in a different language by writing it first in their native language and then translating it (even successful translations of major literary works require the translator to essentially re-write everything). So for experienced programmers using a language in which they are fluent, pseduo-code makes no sense.

However … I once had an Education professor in college who, when discussing bi-lingual learning, related a story of when he was just an ESL (English as a Second Language) student himself. He said that he had real difficulty speaking English whenever he was on the spot, until one day his teacher put him on the spot, but said take your time; first think about how you’d say the answer in Spanish, then say it in English. That moment was a breakthrough for him, because it taught him that he could to use the language faculties he already had to help gain new language faculties. By the time I heard him lecture, he didn’t even have a trace of an accent.

The point of the above is, pseudo-code is an incredibly important aspect of LEARNING a programming language (or a part of a language you previously weren’t familiar with). Trying to do something from scratch when you’re new at it is incredibly difficult, but if you can bring in some of your existing, wrong language skills (like your proficiency in English) and build on that it can be incredibly helpful in mastering the right language.

So that book had great advice … it’s just too bad they didn’t specifically orient it towards new learners, rather than suggesting it’s something programmers who have mastered their language should use.

I only use pseudocode for the most critical or complex functions. In simple, small, uninteresting functions there’s no point in using pseudocode, if its written well enough the function name is all the pseudocode you need (if its not you’re probably doing it wrong).

Some functions will be more complex or critical to the product. In the more important/critical functions I always use the pseudocode approach so it can be maintained easier.

Pseudocode really comes into its own when you’re writing something in a new or unfamiliar language. When I’m not quite au-fait with the syntax and want to get my ideas down quickly and stay in that zone when ideas are flowing without the stop-start google / textbook consultation that comes with writing actual production code in a language you’re not as familiar with.