Monday, 22 February 2010


Some of you may already be aware of the quote:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

I came across this recently at work when I worked on a particularly evil algorithm for visibility checking. The algorithm as a whole is bound by three states, have-recursed, incoming-state, current-state. This, coupled with the fact that the algorithm changes based on each of these states means that the function that handles it looks really large as it has to have six separate code paths. The fact is, it is actually a really big problem space, not as large a problem space as when I wrote my own version of Judy Tables, but big enough. It's the combination of problem space complexity and the verbosity of each of the techniques for finding answers to questions that arise due to the current problem space configuration that means this function bloats into quite a scary pile of ifs and math functions.

I will be attempting to make it readable soon, as a co-worker has pointed out "it doesn't make sense", and that is going to make it impossible to maintain later on. The main thing I have to worry about is that the algorithm seems "okay" to me, but I think half of that is that the maths and the logic flow do make sense to me. But for how long? I'm worried that I might not be able to tell when the code is simple enough. First attempt is going to be trying to function-off the questions and states as much as possible.

Has anyone else had any experience of this? How do you tell when your code is good enough for public consumption?
Post a Comment