POV-Ray : Newsgroups : povray.off-topic : Old fart? : Re: Old fart? Server Time
30 Jul 2024 08:19:55 EDT (-0400)
  Re: Old fart?  
From: Darren New
Date: 20 Apr 2011 10:58:48
Message: <4daef4a8$1@news.povray.org>
On 4/19/2011 23:02, Jim Henderson wrote:
> It's far easier if, for instance, you're using a tool like Source
> Navigator (which I really like for this type of thing) you are looking to
> analyze a bug.  Having an error code and a call stack makes it far easier
> to use a tool like that than to say "I wonder how it does 'x'" and then
> work through the logic.  It's possible, but it can take quite a while.


Here's the thing about that...

There are three steps to debugging a piece of code:

1) Find the symptoms of an error and confirm it's erroneous.

2) Find the program state (i.e., variable values) that isn't as expected at 
that point.

3) Trace back the infected state to the defect in the code that caused the 
original infected state.

4) Determine how to modify the code to no longer have that defect, hopefully 
without introducing infected state that triggers an error from a defect 
existent elsewhere.

An error code and a call stack gives you #1. But if you don't know what the 
program state is supposed to look like, all you have to go on is the actual 
variables that show the error message. I.e., if you don't know even the 
slightest amount of what the data in a structure is supposed to be, then 
having an error message tell you that a particular pointer is null when it 
shouldn't be doesn't help nearly as much as looking at the values and 
determining every value in the entire structure is zero when it should all 
be filled out with good data.

What's the good data?  *That* is what needs to be documented.  Otherwise, 
you're reading the code, trying to figure out what the code *does*, and once 
you do, you *still* haven't even *started* to find the bug. Then you have to 
guess what the author *intended* to have happening there, and then guess 
from that what the state should have been. *Now* you've finished step #1. 
With documentation, all that is tremendously simplified or eliminated, 
depending on how detailed the documentation is.

Saying "the code is the documentation" is like saying "the commercial 
airliner doesn't need maintenance documentation. You can just look at it and 
see what's wrong."

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.