Although I'm a huge fan of Code Complete -- it is my single most recommended programming book for good reason -- there are chapters in it that I haven't been able to digest, even after 16 years.
I don’t know if anyone has mentioned this already, but why not write a compiler for the pseudocode instead of writing the same code twice? It’s much better to write a compiler that compiles from the pseudocode to the real code instead of translating by hand. Writing pseudocode first and then the real code is like manually translating a high-level language to assembly language.
I read Code Complete when it first came out, and this PPP technique is one of the main takeaways I got from it. I use PPP regularly (though not on everything). It’s like making a sketch before breaking out the paints.
It requires a little balance to get the right level of detail in the pseudocode. If it’s too low level, then you just end up with a lot of useless, noisy redundancy (as shown in the example). But, if the pseudocode is at an appropriate level, then the comments become a great roadmap to the function, and the code contains all the hairy details.
I find it especially useful when pair programming, as it’s much faster to come to agreement on how to lay out the logic before getting bogged down with representational details. It’s also good when you’re in a top-down mode. I find I use it less when working bottom-up.
When reading CC it occurred to me as a nice method as well. However, I almost never got to really try it out in writing code. It did help me however, writing some particularly nasty functions.
Also, I find myself resorting to this a lot more in less expressive languages like C or Java than in languages that allow me to write code that reads more like a description of what I am trying to do than like code (I love LINQ in this respect).
The need to keep some pseudo-code comments is a clear sign that the level of abstraction you’re dealing with is to low. In the example you gave I the actual implementation is almost identical to what you wrote in pseudo code. In this case you can either rip the comments if you started with the comments. As an alternative (which I use most of the time) you write code using mocked classes and functions that are your pseudocode and implement them later. Eventually add some refactoring to make the code’s intent even more clear. I found this approach useful especially when programming test first – the final test cases are very descriptive and almost a domain specific language.
With the small group of programmers I work with often, we prototype directly in code.
However, if we’re sitting with a larger crowd - especially with programmers from other groups - we use pseudo code. You would not believe the amount of time spent getting sidetracked bickering about curly-brace style, indentation, variable naming conventions, implementation of design pattern, etc. And this is from people that should know better. Anyway, in those circumstances, pseudo code streamlines things… at least a bit.
I try to minimize comments by refactoring code into useful pieces. Python is writing pseudo while programming indeed !
We don’t often type it out[1] - normally we just converse across the table in pseudo code, and more often join chairs on one side.
[1] the occasional email when working different hours excepted
Then again, most the pseudo code handles design questions, so it comes closer to Beck Cunninghams CRC card sessions. We picture the code and reshuffle responsibilities until there is no / least dissonance left.
At some point we might shelf the discussion as ‘need to think about’. In which case I, for me, like to just close my eyes, listen to some music and think up wildly different. vastly simpler or just fun solutions on my daily 2hour commutes.
It really does give you an edge when coding the thing up. Since you already know what the details should look like, you will continue to follow the main thread and move on to the next hurdle once the first one get’s nailed.
When I’m on a roll, this really is exciting and gives me the green bar once every five to 10 minutes, and just so many commits.
It made my collegue mutter last week: Wow. You really want to reach revision #1000 before month’s end, do you?!
It’s all about effective programming…
… and oranges
attempting to using precise English to describe the nuts and bolts of code
It’s not about writing down precisely what should happen. It’s about getting a general idea of what should happen. It’s an overall view. For me, it is how I work out the algorithm before I code it. I usually mix English in with several computer languages (whichever one has the simplest syntax for what I’m trying to express.) For example, if I where writing a routine that returns the sum of the ASCII values of the logged in username, I might do something like this:
’ Get the current user name
for each letter in name
ct += value(letter)
That’s a mix of VB, C, Python and English. I don’t have to worry about the syntax of the language I’m writing in, I just have to worry about getting my idea out.
I can think of quite a few instances where pseudocode isn’t necessary , or impractical, but I can also think of plenty where it’s use has been instrumental in the success of writing whatever function I’m working on.
I’d only write out some pseudocode for a block of code that isn’t very intuitive to follow or write. For example, I recently had a homework assignment that was to solve the ‘Josephus Problem’ using a C++ STL list. The Pseudocode I wrote really helped me work through the problem more easily.
I used pseudo code a lot. It is a great tool for large scale projects where not everyone is a developer, and you have developers who work in very different languages who need to understand design across the project.
I’ve worked on many projects that had 100 - 200 team members. Not everyone on the project is a developer…sometimes in reading your blog and listening to the stackoverflow podcast I get the impression you have only worked on projects or products that were staffed with 100% developers…what world is that??
We had specialized developers who only did ABAP, C#, HTML/CSS/Javascript, or were DBAs and stored proc developers. No way could they all read each others’ code, but they often needed to understand what it was doing to work together and integrate their piece of the project.
Business people can often understand pseudo code, which is another aspect that is valuable.
I do the pseudocode thing a fair amount, especially if I’m coding something that I don’t specifically know how to code from the start, or if it’s complex enough that I want to get my thoughts in order first. What I’ll do is outline what I want the function to do in comments, and then fill in each comment with code. The comments act more like stubs for functionality (and some of them will end up as functions instead. I wouldn’t necessarily call it something one must practice, but it’s a tool in my toolbox.
I do believe that pseudo code is a powerful technique to visualize the scope of work. Personally I write pseudo a lot specially when I need to design the scope of multiple classes, functions or web pages. It gives me a clear view about the complexity of the work required and it works as an eye opener to highlight the bits and bites of coding level and functions required.
What is the problem in thinking both ways at the same time, if you can think in a general way using pseudo code, then you can embed small parts of technical language specific code in it. But I perceive the pseudo code methodology as an abstraction method of the design (Big Picture of the Small Pictures).
I hope this doesn’t come off as insulting, but if you only think about problems in terms of code I suspect the problems you’re trying to solve are not very complicated. (Either that, or you’re a super genius–but smart as you clearly are, you’re probably not a super genius).
Pseudo-code isn’t a 1-to-1 mapping of 1 English (or German or whatever) sentence to 1 line of Java/C#/Python/Ruby/blah code. Pseudo-code is much more high-level. You can gloss over details of things that are unimportant to the core task.
In a (freakin’ brutal) grad algorithms class, I learned this lesson: explain succinctly the problem you’re trying to solve by giving only enough detail to get the point across. For instance, if you need to find the shortest path from one node to all other nodes in a graph that has positive edge weights, how would you do it? You could write out the pseudo-code to do the whole thing line-by-line, thinking in code, or you could do something like this:
for each node in the graph
run dijkstra’s algorithm to find the shortest path
That’s a lot of actual code compressed into two lines (I guess to be fair, you could also just say: run the Floyd-Warshall algorithm, but that’s beside the point).
The point, though, is just to think in terms of high level ideas, not code-level semantics. It really does unleash your ability to think about more difficult problems when you’re not forcing yourself to think about unimportant implementation/code-level details. It also helps you to work outside the box into which Language X tends to push you: once you have the idea, implementing it in any language is a more trivial operation.
And as a final aside, thinking in terms of recursion–and particularly Dynamic Programming–is helped immensely by not thinking in terms of code, but just high level ideas. Once the ideas/pseudo-code is solid, then you deal with edge cases and semantic details of the code. I would go so far as to say one (or: the non-geniuses among us) can’t solve difficult Dynamic Programming problems by thinking about the problem at code-level.
Then again, most web development and business apps tend to be fairly straight-forward CRUD apps at their core, so thinking in terms of code is probably sufficient in many/most cases like that.
Another brilliant article! You really should title this blog =~ /.*Rebel.Software./
I use this method when I’m coding a very specific algorithm. For example, a function to know if an account is in credit hold: I have to check the expiration date of the account, if the customer paid the monthly fee and if not, how many days has been pass since the last payment… and other steps that needs to be executed in certain order. That’s a business rule that needs to be very well commented in case that somebody get the idea to change one of those steps (and it happens a lot).
So the best way to code one of these functions is writing the pseudocode fist and after really code it, leaving the pseudocode comments there.
Good variable names, accurate method names, thoughtful enumerations, and descriptive boolean tests get me most of the way toward writing code that I can read and understand without too many comments.
If I’m having trouble finding the right names for things, though, I could see the PPP as being helpful.
But to your end, I’ve felt the same way about that chapter in CC: I’ve never really gotten into the swing of things with it.
I write Pseudo code for all my code, 'cept I call em specs! :0) They are actually executable so there’s no way for them to diverge from the code.
~Lee
I’m also a big fan of Code Complete and I use the pseudo-code technique with great success at times. I find it most beneficial when the code will do lots of stuff, and I don’t want to implement it right now, because maybe this is just supporting code to the main task I’m working at. But I normally don’t keep it as comments, because they’re very obvious comments when the code is implemented, and normally I have to create still other methods to fully implement the functionality.
Sometimes I already know the logic but not really know how to write the code yet. For example, implementing something in a new language I’m not familiar with. In cases like, writing pseudo-code does not prevent me to make progress forward because it separates the concern of implementing the logic from implementing the code.