Pseudocode Programming Process

Mon 23 November 2009

So for the last while I've been experimenting with PPP as described in Code Complete. Jeff Atwood has a great description of it on coding horror. You should read the blog post the metaphor of pseudocode as tang is a good one. I've been using PPP for a number of weeks now and so far it's really been working. There have been several reasons why I found it worksbut for me the most important and useful part is purely that it **slows me down**.

One of Jeff's arguments against PPP is that he 'thinks in code', and before I tried PPP I would have said the same. The problem is when I 'think in code', it sometimes results in poorly written code that clearly I haven't spent nearly enough time thinking about. I'm moving straight into worrying about implementation details.

Now, because I'm abstracting the thinking away from the code it's effectively created a new step in programming for me. Now Jeff is undoubtedly a better and more experienced programmer than I, so this is where he bases his argument, however we don't all have this immediate ability to make the optimum choices as we start writing out code. When I say it slows me down, on a routine level, I start to think more about naming, is the function parameters in keeping with the abstraction of the overall class, the boundaries on parameters and other implementation details I may miss. And although most of those points are not at all related to what PPP wants me to think about it's because I'm forcing myself to slow down I begin to become more thoughtful in the part where I fill out the tang. For now at least, I find it difficult to conceptualise all of this on top of worrying about all of the implementation details of the language. I really have shifted my thinking process to a new 'thinking about thinking' stage, that has significantly improved the quality of my code. I do sometimes feel like slipping into old habits, but I know the quality of my code will slip too so for the last while I've been good.

For examplewhen I've had to really think about certain functions it may become obvious that it needs to be split, something I may not have noticed worrying about implementation details, or more likely I'll noticed it needs to be split half-way through coding it. I also know there have been times when I 'should' have split a routine but because I mid programming it I 'leave it for now'. Never a good idea but when deadlines loom….. However when I'm writing pseudocode, if what I'm writing need some serious explaining, it become's pretty obvious that I need to start a new routine. Typically this has resulted in small tight functions that truly adhere to the 'do one thing well' ideal. There are many other examplesbut it all boils down to a procedure that focuses my thoughts.

One tip I would suggest is to write your pseudocode for any language to implement, so I always re-read the pseudocode with an eye to writing it in a totally different language for me it's C(I typically code in PHP). This ensures there's no language details in there.

Another good way to think about it is a GTD to-do list. Basically, 'a person needs to move tasks out of the mind by recording them externally. That way, the mind is freed from the job of remembering everything that needs to be done, and can concentrate on actually performing those tasks.' I feel this step is becoming more and more vital for me and on top of that free well written comments are a terrific bonus for the lazy programmer!

Category: Coding Tagged: best-practice