|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
  Brain Giblets Volume IV | 
Posted - 6/12/2008 11:15:54 AM | For this edition of my series Brain Giblets, I'd like to share a little debugging technique that has served me excessively well over the years.
The great thing about this technique is that it is literally applicable to any situation - regardless of what debugging tools you have available, or even what languages and technologies you may be using, you can always find a variant of this technique that can be useful.
I personally refer to this method as writing event sequence notes. The name should pretty much give away the gist of the technique: the goal is to write down a step-by-step analysis of everything that happens in the code.
Well, you may ask, why not just read the code? What's the point of writing down this event sequence if the code itself already explains what should happen?
The magic word there is "should" - as we all know, debugging is essentially the process of finding out the difference between what does happen and what should happen.
Of course this technique is easiest when you have a debugger and can step through the code in question; but, failing that, using debug logging can be just as effective. Just be sure to log every detail, even if it doesn't seem relevant.
A good event sequence log will show a history of what code is executed; but it will also record key variable values and other state information. Further, you should write the events in prose rather than code. This forces you to really think about what each line of code has done as it gets executed. The net result is that you have a perfect description of how the program gets into a buggy situation.
This technique can be immensely helpful when dealing with very large or complex code bases, because you can prune away all the code that didn't happen and focus entirely on what code is getting executed. It's a method for filtering out distractions and irrelevant data, which helps keep the scope of the debugging challenge under control.
So there you have it. This probably isn't news to seasoned debuggery artists, but hopefully it will be of some use to somebody 
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
