I'm not a pro yet either, but I don't think pseudocode is useful either. I've written out 40+ page design docs, but I never felt that pseudocode would help me implement it. I always felt like it was better to write readable, reliable code (i.e. write test cases upfront in the Design Doc), than to worry about implementation that early in the project. You should do whatever the teacher/supervisor says tho.

Pseudocode is useful for describing/documenting an algorithm in a language-neutral form.

I don't see any value in writing an entire program in pseudo-code and then rewriting it in real code.

I write pseudo-code, to the level of "put the thing in the list, sorted by frobnication."

I don't do it to the level of "get the head pointer of the list. for each list element, look at the frobnication. if the item to be inserted has higher frobnication, set the next pointer of our previous link to point to our item, set the previous pointer of our next item to link to our item, and make the previous pointer of our item point to the previous item, and the next pointer of our item point to the next item."
That'd be plain silly -- that's what good variable names are for.

The nice thing with pseudo-code is that it works very well as commenting. I e, when I write a new function, I'll write what the function is supposed to do in 3-10 one-liners, and then I write the code for each of the one-liners, keeping the one-liners as comments.

I'll write Pseudocode when I'm not at a computer or don't have access to a computer at the time I have a good idea. I've never heard of it being used to actually writing a whole program (wierd)?? as some of the above posters have suggested it being used for.

I've used Pseudocode in cases where I wanted to test the feasibility of an algorithms that would take too long to code and test in a real program. I've done this for terrain rendering algorithms that I tested first on paper. Implementing it on a computer would take too long, graphic setup, variable setup, project setup etc.. Sometimes for the larger picture it is good to detach yourself from your computer, it helps to spur new and good ideas.

Quote:Original post by Phineas
For my final project in CS this semester I had to first design the program completely in detailed pseudocode - every little detail about the code had to be in the pseudocode without abstraction of any kind. I found it extremely tedious, as I am used to "playing as I go". Normally I do stub out all functions and make list of input/process/output. For me, that's enough.

I'm wondering, does anyone, indie or professional, pseudocode their games before writing real code? To the extent described above, or only minimally?

Usually only college freshman have to write pseudo-code. With the advent of macro-assemblers (decades ago) it stopped making sense to pseudo-code anything. With a crude assembler (e.g. debug.com) you can see how pseudo-code would be very useful.

You might work a particularily complicated part out on paper, but no one in the entire professional field of software engineering would ever write pseudo-code to that detail (unless they're writing a textbook for college freshman). There's more general business reasons not to do such a thing; whenever something is recorded in two places it takes work (thus time & money) to keep them synchronized and worse yet human transcoding results in mistakes. (i.e. it doesn't matter if the pseudo-code is perfect, you're going to screw up copying it in to C and you're going to have to debug it to fix these mistakes, you can quote Donald Knuth about this principle "Beware of bugs in the above code; I have only proved it correct, not tried it.".) So to justify this cost there has to be significant value for the work performed. If you're going to do it twice, do it once using a real CASE tool which will emit skeleton code for a head start with the second pass.

[Edited by - Shannon Barber on April 22, 2006 1:36:13 AM]