Introduction
This will be a short post because I’m still moving times during a crunchtime at the office (Bad Timing). I hope I will have more time to prepare my next entry.
Today I want to write about some small techniques I use quite often when writing code. Especially for code where I’m not 100% sure how to tacle the problem best.
End to Start
Where do you start when you have the task to program a complex system? I normally use a technique that afaik has no real name (I will call it “End to Start Design” for this Post) that I find really useful: Start at the end of the problem!
The purpose of code is to transform data (Thanks to Mike Acton for his clear words on this) and if you have a bunch of code it does lots of transformations that are dependent on each other.
We now have the option to start and try to code the whole transformation path from start to end. This has the big problem that we normally don’t fully understand the whole problem and don’t really foresee the minimal set of data for each transformation stage. We then waste time/energy on developing code that does transformations we don’t need or want in the end (It’s really easy to overengineer the problem when starting from the front).
So I start thinking about the problem from the End: What is absolutely necessary to get the effect displayed in the game? From that I go back to find out what data I’ll need in each stage. This ends at the point where I know what the original input data for the system is (which usually is input by Level Designern/Artists/Other Code System).
Think about it this way: By starting at the end We have a really good set of requirements for each stage because the final requirements are (hopefully) defined by someone and for each stage before that you exactly now what data you need because you already wrote the code for the next stage. And clear requirements and a small scope make the actual programming part a lot easier.
I usually start out on a whiteboard or on paper and think about the data and the transformation steps required to transform it. After some thinking about the problem (not too much ;)) I discuss my design with a collegue and start to write the *last* transformation function.
It’s normally really easy to come up with test data in exactly the format you need (either just create some variables on the stack or write a simple ruby/perl/bash script to create a set of input data).
PDL
With a clear task and test data at hand I start up my IDE and start to write the function. For complex transformations (everything that is more then a few lines) I use another small technique called “PDL” (for Program Description Language). I read about PDL in the book “Code Complete” which I wholeheartedly (sp) recommend to every programmer.
I use PDL to write down a high level description on *what* the function should do (I try to not write anything about *how* the code will solve the problem). I normally write the prototype of a new function and put down multiple single line comments describing each single step you can think of to get the final result. In essence this is a simple top-down breakdown of a problem into several smaller sub-problems.
After that I would write the code for each step underneath the description line. This has the advantage for me that I can reason about the problem on a higher level and after that *just* have to write simple code for each step. And I get really good comments in the end!
Ok, normally that process is a lot less streamlined then I told you here. I usually iterate on each step quite a bit until I’m happy with everything, but the breakdown of the problem into a data transformation pipeline helps a lot when refactoring code as well. Even if I have to change big parts of the implementation around I usually can reuse some transformations in the new pipeline with small adjustments.
Conclusion
OK, I guess this article would have been a lot better with examples, diagramms and someone proof-reading the post before I published it, but on the other Hand it might just not have been finished at all that way. Hopefully it’s still useful to someone and I hope to get some info on techniques you use (in the comments or in another post).