Pseudocode or Code?

It reminds me of the academics walking though a new and very successful factory that was the brain-child of a student from the school of hard knocks who had no formal education.

They look at the unique factory layout, the novel machinery and employment arrangements. In the end they concluded “Oh yes, sure it works in practice, but it would never work in theory.”

Okay, that was fictional, but the point is that when someone becomes too academic they can start to focus on theory over practicality. So for the reasons Jeff lists, I agree with Jeff.

But from what I’ve read of the comments the conclusions are that the theory is sound, when placed into a practical framework. And that’s where I sit – I’m on board with the TDD camp.

I find that pseudocode is useful when you pick the right level of detail. When you think of all the things that you need to do and you write them down it helps ensure that you don’t miss anything.

Sometimes psusedocode can be as simple as a TODO list that you fill in with code.

I pseudocode in comments and kind of wireframe the thing up before coding. It helps decouple the design process from the coding process which to me is A Good Thing. If I pseudo-code up a routine, other design options become apparent such as a need for different encapsulation, and logic errors or faulty assumptions show themselves before I have invested the time in writing the code.

Once the comments are there and the workflows are clear, the coding becomes that much easier because you are not iteratively second-guessing your design decisions as the bigger picture slowly reveals itself to you. I can also feel free to stop working at any time and come back to it later without worrying that I’ll forget what I was doing. I like anything that encourages me to stop working. :slight_smile:

It’s worth noting that this really only fits a particular right-in-the-middle size scope of developing task… If something is big and complicated, you do a more formal spec for it and start there. If something is small and trivial, you just do it.

@dbr

Even more so: Erlang

Yeah, someone already said that pseudocode is something you’ll only use at school. I think it has some use in algorithm design as well, but that’s only because an algorithm happens to be a very clearly defined problem - it’s somehow natural to go over it with a quick pseudocode before you actually do it since recursive functions and whatnots are sometimes pretty tedious to tackle straight on.

The idea that you should leave all the pseudocode as comments on your code is about the worst idea i’ve heard in a while - if you’ve ever read over commented code you’ll know what i’m talking about. It’s no longer fun when you have a comment on every other line of code (or worse for that matter). I mean who would like to read something like this:

// if a is greater than b
if (a b)

This kind of thing only manages to serve two audiences - programmers and designers - but that’s about the only upside i can see for it.

Pseudocode only gets written in my Brain, which I translate to real code whenever I code - that makes is almost self-commenting such that few comments need to be added in the end.

When I first read this, I thought it was a great idea (I was a very junior programmer looking for structure). But yeah, it wasn’t long before I came to realize it was completely impractical at least the way I interpreted using it.

But ocasionally, I will use it now. Usually if I have some huge process (stored procedures especially) where I want to nail down the process before I get caught up in all the details.

When I first read this, I thought it was a great idea (I was a very junior programmer looking for structure). But yeah, it wasn’t long before I came to realize it was completely impractical at least the way I interpreted using it.

But ocasionally, I will use it now. Usually if I have some huge process (stored procedures especially) where I want to nail down the process before I get caught up in all the details.

I found writing pseudo code useful when I have to write the complex routines. I do not use any formal method for it, I just use eclipse to do it.
I think we write the pseudo code when the complete code of the routine if not clear in our mind.

Pseudo code is only useful to me when I have Coder’s Block. I, like you want to think in the code then go back an add comments as needed to make my code clear.

Do you write pseudocode before writing code?

Normally, no. If problem is not too complex, I only write my purpose as a comment, not the algorithm itself.

If problem is complex, I write pseudo code for a reference for only myelf and try to clear after implementing the real code.

In complex problems I mostly change my algorithm several times during coding; leaving pseudo code comments may misguide the posterior programmers, so I try to clear all pseudo codes and write comments for:

  • What the following algorithm is purposed for
  • Inputs and outputs

The major, major problem of pseudo-code is semantics. If you describe something (say, an algorithm) with a certain notation (say, pseudo-code, or flow-charts, or whatever), then you need semantics. What does if error code is valid then dostuff mean? Of course, by semantics of the english language, this means: There is a condition hidden here, and whenever the condition is true, execute dostuff. In a recent lecture, this resulted in horrible misunderstandings, because the semantics of return appeared to be output the value after the return and continue execution after this. The result was a horrible misunderstanding with regard to the algorithm.
The usual way to obtain a semantic for this pseudo-code is by mimicing an existing language and using the english language semantics. However, given this, I second Jeff: It makes no sense to use pseudo-code, because pseudo-code will always look like an existing programming language, and well-factored code in a high level language (say, prolog, haskell, python/ruby) will look like pseudo-code. In fact, whenever someone asks me for pseudo-code, I write down a program in one of these languages (maybe with a bit of syntactic convienience, but usually, those could be eliminated with a simple preprocessor).

However, the deeper question is: Is there a need to have a better representation of complex code to reason about? I say yes, and yes, sometimes it is necessary. For certain compiler operations, for example, it is hilariously helpful to just draw two tree diagrams (before transformation, after transformation) instead of writing several pages of text about it. In other areas, a simple block diagram with a little statemachine next to it can help a lot. In other areas, a simple dataflow diagram will help a lot. The important thing to notice about all these representations however is: They are not trivially isomorphic to code. Take most pseudo-code, and it is fairly easy to write down the code for this line of pseudo-code. This is bad. This is very, very bad, because it means: pseudo-code is a very, very thin layer of abstraction, and thin layers of abstractions are just an obstacle. Given a dataflow diagram, or two trees and an arrow from one to the other, it is certainly not trivial to actually program this. This is a good thing, because apparently, the abstraction is big.

So, dont use pseudo-code, because it is a weak abstraction, use a good (ad-hoc) diagram to explain this. If you need the diagram more often, write down a little formal explanation of it and be happy :slight_smile:

Yes i do.

Not a pseudocode mayb, but something like it. My coding plan is simple. First is simple model, comonnly on papers, shemas and pictures.
Then i create structure of desired code by comments. And finally - code.

And that’s work great for me.

I don’t know, but i feel Pseudocoding when TTD’ing.

I have to disagree with your decidedly negative statement concerning writing pseudo code.

As a sophomore Computer Engineer, I have found that pseudo code has helped me on many occasions to obtain an overall framework for the project that I was about to commence.

The flow is simple, and allows for a basic form of debugging in the very beginning. Remember, if your logic is flawed from the beginning, no code that you write will be able to fix your problems.

My 2 cents.

There are folks who use really abbreviated variables to fit 24x80.
A bunch of BSD/Linux code is like that.
Comments become really helpful in such situations.

I think it totally depends on a) the type of programming being done and b) the language(s) being used.

For most web-dev stuff that isn’t heavily on algorithms or trickery (using well written libraries with sane method names) PPP is probably overkill as the code itself (should) be readable enough even for non language geeks.

If you are writing something tricky or highly complicated though in say ANSI C, then the PPP starts to look like an easy way to eliminate bugs before they are even created.

Hi, Jeff

I think you are right if you say, that thinking about code is in code (not in plain english). At least for me. I dont write pseudocode to start coding, I rather write some of my comments in pseudocode while coding. Although I almost constantly draw class-relations, important methods and Membervars, while coding on complex problems.

I was taught this technique in college, and I used to do this quite often in my first several years after college to help me think through a problem. I think it’s very useful for someone who is fairly new to programming - your brain isn’t wired yet to think in code. As I got more experience under my belt, I gradually stopped thinking in terms of pseudocode and started thinking in pure code, at which point it became a redundant exercise in most cases. I agree with some other commenters, though, that it can be a useful trick for even the most experienced programmer when designing a very complex routine.