How useful is pseudocode?

[morphy_richards]

Hello all,

There's an interesting discussion going on in an education forum elsewhere (sadly I cant link to it) about the pro's and cons of pseudocode.

To brutally summarise the discussion.

Pseudocode is essential and programs should be planned using it in detail before actual coding begins.
Pseudocode cannot be tested or debugged and is in effect just writing the code out twice.
Writing pseudocode before coding will mean you will write more efficient code as you wont just stick with the first thing that works.
Damage has already been done by focusing on the syntax of particular languages, during early learning. This makes it difficult for people to adapt to different languages later
Pseudocode is only bound by the rules of English, and not necessarily logical, therefore of limited use for learning about computational thinking....

I'm interested in seeing what others have to say who are from a wider community. Any other thoughts?

[croston]

I will post a more detailed reply in the other forum in question (I've been following that thread).
To summarise: I hate using and reading pseudocode in the real world. It may have it's uses in teaching - I don't know because I am a professional coder and not a teacher. A bit like teaching scratch really - scratch is only ever used for teaching. Don't get me started on workplace coding standards and formal code documentation though....

[ShiftPlusOne]

Is this about forcing students to write pseudocode or suggesting it?

[rpdom]

I sometimes use pseudo-code to sort out the idea of program flow and what I want to do. Then I convert it into actual code.

Sometimes I will use pseudo-code for examples of how to do a particular process. In this case writing it out in actual code is forcing the person reading it to use the language specified and the given code, when they could be using the language of their choice and coding it in their own way.

I wouldn't write a whole program in pseudo-code. That would be pointless, as most of it can usually be coded directly without any problems.

[rurwin]

It depends what you mean by pseudo-code.

I've been programming all day and every day now for almost 40 years, I have O, A and BSc in Computer Science, and the only time I've written the pseudo-code I think you are talking about, was when a teacher or exam told me to... or maybe when I was showing someone else how to pass exams.

On the other hand, if an algorithm is particularly fiddly, I will do something like this:

DblLinkedAdd.gif (183.82 KiB) Viewed 5397 times

That is the closest I ever get to either pseudo-code or flowcharts.

And it isn't part of the documentation for the project. That will be written up in UML... probably after I write the code.

(Copyright waived on the image, if you want to show it around.)

[Ravenous]

I think pseudocode, or more precisely the sort of semi-formal methodology implied, will work well if you're writing code once for each application, from scratch, and everything is well defined. I could ramble on about the one time I used a fancy methodology (in an academic exercise) which included pseudo and other things. Perfect for the job.

It might work for intermediate applications too - less strict than the above list of conditions.

But such formalities may be less convincing for very long life cycle code where it continually gets bits added in over, say, fifteen years. The flowcharts would be too vast to read; the dataflow diagrams would have umpteen different versions depending on the customer's configuration.

Some customers change; they need extra bits added in years after going live and it needs to work at 6am on the first morning across a hundred branches; years later they need more bits in the same area; they pay you for the change and don't want their competitors (who also use your software) to get it. (I've said too much, I may have to kill you now.)

As for "Writing pseudocode before coding will mean you will write more efficient code as you wont just stick with the first thing that works" - I think this is wrong. You'll stick with the first bit of pseudo that looks like it'll work, and convert it to your final code.

The bit about particular language syntax is probably right though; the raspi is making me finally lose my Python cherry and I'm finding the nested/indented structure really weird right now, though I know it's logical and unambiguous.

Short answer - it depends on your product, the life cycle considerations, how "rigorous" it needs to be, etc.

(ps - I predict this thread will either die after several more posts or will turn into an almighty flame war!)

[morphy_richards]

Is this about forcing students to write pseudocode or suggesting it?

Both, I suppose

[pygmy_giant]

When I did my City and Guilds in C++ we were told that roughly drafting code in english sentances was a necessary part of preperation. Of course I ignored this as I assumed mysef to be an automatic genius. Recently however I have started to do it as I have got sick of re-writing things after spaghetti coding myself into a corner. It seems like a ball ache before you start but actually planning programs on paper/wordprocessor rather than on the fly in your head does make you think about the best way of doing things and what you are trying to acheive and how you are going to do it. For simple programs it may not be necessary, but for anything exciting its definately worth a considering as it saves time and anxiety in the long run.

Many people would plan an essay, letter or personal statement on a job application before launching into it so why not a computer program?

I guess an additional advantage is that pseudo code can be kept and referred to later to understand the program involved should it need adapting or translating into another language.

I guess the more important question is what is the best way to pseudocode and how much detail to put in. I just use pigeon english and tend to use it only for tricky procedures. If it looks too much like actual code then you are probably duplicating work.

If I had to teach programming I would start off by teaching pseudo code as it is accessible and helps kids to understand what 3G languages can do.

[Rene_is_I]

Whilst studying one of my lecturers always said "think more write less" and it makes sense.
A good way to make notes while thinking about the programing task at hand is by making use of pseudo code and flow charts.

[DaveDriesen]

Pseudocode definitely has its uses:

Quality & compliance
Your organisation may be subject to stipulations that certain documents MUST be language agnostic.

Not everyone is a hacker
You'll know what I mean if you have contact with customers, management, architects, engineers..

Not every topic is even related to programming
Process management, organisational structures, ..

You don't want a flame war on your hands
People might take offense if your documentation is biased towards certain languages.
(i.e. Java, that's not a programming language, it's script kiddie BS.
If you took offense to that just now, then that proves the point)

Your devs may be smart but your guru's even smarter
You can face a need to explain a tremendously complicated concept to adept coders.

Likewise, however smart you are, there's always someone cleverer than yourself
You're pretty smart. I'm pretty smart. One thing I learned over the years is that there's people out there who are just, simply, WAY smarter. When you meet such people, you'll be glad they used pseudocode to explain their ideas. Check out some of the papers at ACM or SIGGRAPH.

Nobody probably likes pseudocode, but it's good that it's there.
Forcing it on people out of principle, is lame though.

Dave Driesen
Linux dev and oldskool elite

[redhawk]

Most of the time when I'm coding I already have a mental imagine of what's going on and how to progress so I'm not in the habit of using pseudocode.
Having said that if I'm having problems I cannot figure out or I'm dealing with extremely complicated logic with multiple pathways then I do sometimes doodle on a piece of paper.

Whether you use pseudocode depends on the person and how confident they are as a coder, it's certainly useful for problem solving but I wouldn't use it willy nilly.

Richard S.

[ShiftPlusOne]

Is this about forcing students to write pseudocode or suggesting it?

Both, I suppose

As a student and someone who codes for fun, I would absolutely hate to be forbidden from diving into the real code or having to write pseudocode afterwards simply to meet some assessment criteria. That would quickly kill my interest in the subject.

Having said that, I find it to be a handy tool. When writing assembly code, I used to write pseudocode first and that would help me break the problem down into smaller pieces. When working on an algorithm that I don't know, I tend to do what rurwin does - a bit of pseudocode and/or diagrams to help my brain churn it over. I also appreciate it when algorithms are introduced in pseudocode to make them easier to understand.

However, that's all preference. Some may use it, some may not. Anyone who cares about programming will find what works for them, ways to improve their code quality, their efficiency and so on. So the job of universities may be to introduce good coding habits and techniques, but not strictly enforce a technique on all students.

In short, suggesting - yay, forcing - nay.

[fbutler]

Is this about forcing students to write pseudocode or suggesting it?

Both, I suppose

It's like anything else, sometimes it's useful, and sometimes it's not required. If I'm coding I don't use it as I normally visualise what it is that I'm going to be doing in my head before I code. However if I'm explaining concepts to other people I sometimes use it along with diagrams etc. So it is useful, but shouldn't be forced on people.

[johnbeetem]

Pseudo-code has its uses. It's a great way to describe an algorithm in a language-independent way, so that others can implement it in whatever they like. Pseudo-code removes the distraction of ugly syntax and lets you combine whatever features you like from various languages or your own imagination. For example, I far prefer Pascal control structures to C's and dislike needing a "break;" after almost every clause in a C switch statement. OTOH, I prefer C's use of braces instead of "begin... end" and I also like the Occam/Python use of indentation to define block structure. So with pseudo-code I can use whatever I feel expresses my algorithm in the cleanest way.

Pseudo-code was a lot more useful when languages didn't express things like data structures and recursion well. When I got started in this biz, your choices were mostly Basic, Fortran, and assembly language, so writing pseudo-code using Pascal control structures and drawing flowcharts were helpful steps for getting your program organized and debugged before giving it to a computer. This was also the era of punched cards and/or limited time-shared access to computers, so you spent a lot of time thinking and planning and debugging off-line rather than hacking at your source code until it seems to work. You could easily see the benefits of off-line tools that reduced the number of runs and/or signing up for computer time in the middle of the night.

Nowadays the languages are better, so the benefits of pseudo-code are less obvious. However, if you find that your pseudo-code is easier to read and understand than real code, it does say something about the language you have chosen.

[Sciman]

What do people here think of this style of pseudocode AQA GCSE students have to use:
http://filestore.aqa.org.uk/subjects/AQ ... B-PSEU.PDF ?

The GCSE students are not expected to stick to it themselves when writing pseudocode (according to the specification) but this is the only code that appears in the language agnostic exam papers.

Sciman (aka simply Chris Roffey over on CAS)

[MattHawkinsUK]

If you have clarified your requirements, designed your system, identified functionality and thought about the flow of data then pseudocode can be a waste of time. With a modern development environment you can probably write real code faster than remembering a pretend syntax.

The times I tend to use it are when I'm trying to work out an algorithm or a complicated mechanism and I want to get the raw idea on the page without worrying about missing bit of punctuation or misspelt keywords.

[rurwin]

The design grows non-linearly in the brain by an intuitive process, and nothing is as fast as thought no matter how rushed and abbreviated. No matter how you represent the design on paper, you will slow the design process. If you can hold the entire design in your head, then that is the fastest way to program. By using a constrained paper format such as flowcharts, pseudo-code or any other such as UML or Z100, you slow the design so much that you can be in danger of losing the thread. Speed is the key; if you can get the design down on paper or code in whatever rough, ad-hoc methodology seems best at the time, you can capture the design before it overflows your brain and without slowing so much that you lose it. But if you constrain yourself to write neatly, to write the documentation before the code, you have to fall back on linear reasoning. That is always slower, less effective and, with sufficient experience, no less error-prone.

Pseudo-code, flow-charts, state-diagrams, relationship diagrams and all the rest are useful tools to have available when the time comes to scribble on the back of an envelope. They are also the way code should be documented and explained. So they should be taught. But they are not, and never have been, the way code is designed. A course should never mandate their use as a design step, especially not in a neat, documentation-ready format.

A newbie programmer, whatever their age, will always make more errors if they code before they flow-chart, because the intuitive vision will be incomplete. However it is the experience of the intuitive design flowing into code that is the hook that keeps them programming. There is no hook in writing a neat flow-chart -- you only have to ask programmers how much they enjoy writing documentation to prove that. So teach program design as a flowing intuitive process backed up by ad-hoc tools that improve the efficiency of the intuitive process by highlighting where the design is incomplete.

Pseudo-code would not usually be the tool of choice; flow-charts, state-diagrams, class-hierarchies and relationship diagrams are probably more useful more often. But it does have a place maybe, as I showed above, where small pieces of intricate code have to be designed.

[rurwin]

What do people here think of this style of pseudocode AQA GCSE students have to use:
http://filestore.aqa.org.uk/subjects/AQ ... B-PSEU.PDF ?

I don't like it; it is obviously written by someone who knows C and little else, trying to design something that looks like a programming language.

• Array indexes should be array(x,y) to match mathematical usage and every other usage on Earth except C and its derivatives. I would accept square brackets to avoid confusion with parentheses. Do not use [y][x] unless you are intending to teach Iliffe Vectors, and you are not.
• The file operations are needlessly ambiguous. For example WRITE value AS LINE n OF file is much easier to understand than WRITELINE(file, n, value), which will always require an explanatory comment.
• LEN is a pointless abbreviation. Use LENGTH OF.
• # may be a wrong choice. Consider marking comments by using a different font or style. But comments within pseudo code will usually indicate an inadequately expressive language.
• CASE...ELSE is a needless reduction in vocabulary. CASE...OTHERWISE reads more easily.

The purpose of this pseudo code is to elucidate an algorithm. It should be, first and foremost, easy to understand. Nobody is going to write a compiler for it. Nobody is going to write a 3,000 line program in it.

[johnbeetem]

• Array indexes should be array(x,y) to match mathematical usage and every other usage on Earth except C and its derivatives. I would accept square brackets to avoid confusion with parentheses. Do not use [y][x] unless you are intending to teach Iliffe Vectors, and you are not.
  ...
• LEN is a pointless abbreviation. Use LENGTH OF.

The last time I looked, mathematics used true subscripts below the base line. Parentheses are so you can keypunch it on an IBM 026 keypunch. Brackets require an IBM 029 keypunch. We deserve better in the 21st Century.

Similarly, I prefer using |x| for length.

JMO/YMMV