Pseudocode or Code?

blog
101

I think a flow chart works better than pseudo code and it’s both more readable (to everyone) and less ambiguous. It’s a bit more work but it’s more valuable as documentation.

Pseudocode has its use for helping you wrap your mind around a problem, but i don’t usually feel the need to write things down to make this work - unless it’s a lenghty and complex problem, though if this is the case then it’s a sign that you need to break the problem down into its components and think about each one separately - divide and conquer.

102

I use pseudocode often for medium sized problems with procedural complexity. I.e. problems that certainly need some subroutines, but not complex enough to justify UML designing.

Pseudo code is just another way to make you feel more secure at what you’re doing by boiling a few hundred lines of code down to something you can grasp. On a good day you don’t need it, on a bad day you’re grateful for all the help you can get. Just like pair programming.

As for leaving the pseudo code in comments - depends on whether it adds information to the code. Meaning if it’s a good comment it stays, but not for the sake of keeping pseudo code.

103

That is actually about the only thing I regularly use from the book. I work in a partnership with a non-technical person, and we can both work in sentences. Then it’s my job to turn those sentences into code.

I love it. The comments actually help me a lot when I take the time to really do it.

Anyway, works for us.

104

I suspect McConnell suggests this because writing comments forces you to verbalise your solution. If you agree that you don’t really understand a problem (and/or its solution) until you can put it into words, then you must agree this approach is worth something.

It’s something I do myself: write down in your editor (as comments) what the code should do then gradually turn the comments into real code. You’ll probably delete most of the original comments along the way.

Obviously if the code is simple enough to be written straight off then you don’t really need to do this.

105

(didn’t read all other comments…) Code should be as difficult to read as natural language. That’s because: 1 code is language and 2 there is nothing natural about natural language. Systems of references, both. Current programming languages are awkward…

106

Do you write pseudocode before writing code?

yes, when some n00b compsci student brings me his class assignment and i find it challenging yet i don’t wish to spoon feed him. of course after writing the pseudocode i lose all interest in the program because after pseudocode, there is nothing else to do but type.

also flowcharts help in this alot.

i find pseudocode a means to think aloud when i can’t concentrate

107

Do you write pseudocode before writing code?

yes, when some n00b compsci student brings me his class assignment and i find it challenging yet i don’t wish to spoon feed him. of course after writing the pseudocode i lose all interest in the program because after pseudocode, there is nothing else to do but type.

also flowcharts help in this alot.

i find pseudocode a means to think aloud when i can’t concentrate

108

Do you write pseudocode before writing code?

No. I practice TDD, so my tests help me with my design, not pseudocode.

Pseudocode makes reviews easier.

So does tests. You look at the tests and you know exactly what code should do.

Pseudocode supports the idea of iterative refinement.
Pseudocode makes changes easier.
Pseudocode is easier to maintain than other forms of design documentation. With other approaches, design is separated from the code, and when one changes, the two fall out of agreement.

It’s really interesting, that all these things can be said about writing tests (whether practising TDD/BDD or else). And with the named downsides and upsides, that other techniques possess, there’s no reason to choose PPP.

I can see how pseudocode was a more useful technique, when programs were written in C and other lower level languages though.

109

Do you write pseudocode before writing code?

No. I practice TDD, so my tests help me with my design, not pseudocode.

Pseudocode makes reviews easier.

So does tests. You look at the tests and you know exactly what code should do.

Pseudocode supports the idea of iterative refinement.
Pseudocode makes changes easier.
Pseudocode is easier to maintain than other forms of design documentation. With other approaches, design is separated from the code, and when one changes, the two fall out of agreement.

It’s really interesting, that all these things can be said about writing tests (whether practising TDD/BDD or else). And with the named downsides and upsides, that other techniques possess, there’s no reason to choose PPP.

I can see how pseudocode was a more useful technique, when programs were written in C and other lower level languages though.

110

Do you write pseudocode before writing code?

No. I practice TDD, so my tests help me with my design, not pseudocode.

Pseudocode makes reviews easier.

So does tests. You look at the tests and you know exactly what code should do.

Pseudocode supports the idea of iterative refinement.
Pseudocode makes changes easier.
Pseudocode is easier to maintain than other forms of design documentation. With other approaches, design is separated from the code, and when one changes, the two fall out of agreement.

It’s really interesting, that all these things can be said about writing tests (whether practising TDD/BDD or else). And with the named downsides and upsides, that other techniques possess, there’s no reason to choose PPP.

I can see how pseudocode was a more useful technique, when programs were written in C and other lower level languages though.

111

Do you write pseudocode before writing code?

No. I practice TDD, so my tests help me with my design, not pseudocode.

Pseudocode makes reviews easier.

So does tests. You look at the tests and you know exactly what code should do.

Pseudocode supports the idea of iterative refinement.
Pseudocode makes changes easier.
Pseudocode is easier to maintain than other forms of design documentation. With other approaches, design is separated from the code, and when one changes, the two fall out of agreement.

It’s really interesting, that all these things can be said about writing tests (whether practising TDD/BDD or else). And with the named downsides and upsides, that other techniques possess, there’s no reason to choose PPP.

I can see how pseudocode was a more useful technique, when programs were written in C and other lower level languages though.

112

I use pseudocode rarely, almost always in complex routines, when I need to work out exactly what needs to happen, it helps me sort out the logic ahead of time.

113

When I was learning, this is how I used to deal with programming big blocks of code that I didn’t understand. I wrote my first linked list walker/sorter in commented pseudo code, then added the code. It just works for me, but I can see why it would drive some people nuts.

114

I do this all the time for particularly complicated pieces of code. Except I don’t write it as pseudocode, I just write what I intend to do as comments, one thing per line and then fill in the code below each line.

That way I ensure that I say what the code DOES instead of how it does it.

115

append array A to B, eliminating null values on the way

In pseudocode, that’s a one-liner, single step. Understandable. But if you try to do that in code, you suddenly get lost in the details: I have to extend the length of array B, possibly by creating a new array and copying all of B over, then reassigning B, then going through each element of A to see if it’s null and… Wait, why am I doing this again?

val c = (a ++ b).remove(x = x == None)

That was pretty straight-forward and clear to me. Now, if I were to implement the append and the remove functions right there, it would be a serious problem with the level of abstraction.

So, perhaps, there’s one more reason to avoid pseudo-code. Maybe it obfuscate such problems.

116

I use pseudocode for tracking flow - before I get bogged down in the implementation details, I trace out what’s going to happen, and make sure that everything goes in the right place. I find code is great for what, comments cover the why (which is usually where the problems are).

117

The problems with pseudocode and other less code and more english programming techniques is that human languages do not do well in describing algorithms or other programming concerns. If they were, we would have real natural language programming.

In my experience, I often write ‘almost code’ which in most cases is very close to final code, and with additional comments to where human level and environmental concerns are not reflected well enough in the language. After I am satisfied with my design, meaning that I believe I have a good structure, have validated my interfaces, and have adequately reflected the algorithms, I then make a pass or two through the code and bring it up to real code and make additional changes headers, comments, etc to conform to whatever standards the project uses for its walk-throughs.

This way I have tailored my efforts to reflect the way I work most efficiently, but recognize that fairly early in the process, I need to communicate the results to others. Usually nobody is completely pleased with project coding standards, but when the size of the programming staff is greater than one, a common compromise must be used.

When I return to old code, either mine or someone elses, it is surprising how often that when I have problems locating an error, running a copy of the code through a tool that removes comments results in my reading exactly what the machine is doing rather than what the original programmer thought was happening and enables me to locate a previously hidden logic problem.

In both cases (producing new code and maintaining legacy code) I accomodate project standards as well as job realities while allowing me to work the way I have found to be most effective.

As far as maintaining pseuodcode or other detail design works, after 30 years of programming, I have yet to be on a maintenance project that provided me with pseudocode level documentation. I rarely even have been given high level design documentation. When detailed design documentation is available, it has never been kept up to date.

Literate coding with short explanitory comments when necessary are the best tools for effective maintenance targeted documentation. Boiler-plate comments and pseodocode are useless.

118

I prefer coding without comments, in that I want the code to be as self-explanatory as humanly possible. Don’t get me wrong; comments do occur regularly in my code, but only because the code could not be made any clearer without them.

Although I agree PPP is overkill, I find comments like this hard to justify.

Every day I see very complex blocks of code with no comments what so ever. When I ask a fellow programmer why they aren’t commenting they give me this same line. Comments take to long, easy to read code is better than commenting

Then 6 months later we find a bug that I am assigned to fix. I ask the original programmer what the complex block does. They have no idea. They will have to study it for 10-30 minutes to wrap their head back around what they where doing/thinking at the time.

Code is always easy to understand 1 minute after you write it.
Code that took you spent several hours/days planning and writing will seem very logical at first.

It may not be quite as obvious to the next guy who comes in after 6 months without the knowledge of everything you learned in the planning stage.

119

I use this fairly regularly although many times the pseudocode doesn’t stay around as comments in the final version. I use it as a design tool to help lay out the process I’m trying to achieve in the domain space before translating it into nuts and bolts of code. It helps to lay out the general flow of the solution and discover any area you may not have a clear picture of yet.

Since most of my coding projects these days are for myself and pushing into areas where I’m still learning, I find it easier to write out the general plan first and then dive into the details of how to actually accomplish it.

In addition, most of my coding is done in a high interrupt environment, either at home (kids) or in between meetings and other distractions at work (I’m a manager now and me producing code is fairly low down on the priority list, that’s what my superstars are for). By laying the work out in pseudocode first, I can get the design done up front and then spend my short bursts of time available for coding on fleshing out the details without loosing the big picture.

120

So does tests. You look at the tests and you know exactly what code should do.

No you don’t. The issue of how the API behaves is somewhat orthogonal to how the code behind that API works. It can be full of bugs and spaghetti code and still return the right thing to your particular test case.

Besides, tests I’ve seen from TDD proponents usually don’t even cover half the branches in their own code, don’t test for exception safety or concurrency, don’t test failure recovery. They just test each piece of their code under the most optimal circumstances, just to verify that the code is there and when right parameters are passed in it does something. They never venture into those catch blocks, never abort the thread while test is in progress, etc.

If you’ve started your career as a tester (as I did) - that’s weak sauce. We were expected to WRECK the system, and wreck it we did. I’ve found probably thousands of super-critical bugs that would never have been found through TDD. In one particularly nasty case, the system would just hang after running happily under load for two days due to the developer non-atomically decrementing a counter in his thread management routines and causing an integer underflow. To investigate, I had to dump the RAM and look at the disassembly in the debugger. How do you find this through TDD? If you can’t find this through TDD why even pretend that your code is bug-free?