Dubuggers? Why?
10 messages in this thread
Mike,
Actually I like function prototyping a lot. But, with an SDB I can really
do some important stuff. For example, suppose I write a program that parses
a file and produces output based upon the contents of that file. If I use
prototyping, I will know:
1. Is my argument list correct for each function call? 2. Are my return
values assigned/not assigned properly?
If I use an SDB after I write each module, I will know:
1. Did I pass the right arguments to the module? 2. Are the arguments used
properly? 3. Are my loops correct? 4. Am I getting sane return values? 5.
What happens to the data; when its read, when its processed, when its
output? 6. What is a particular piece of code LIKELY to do under certain
circumstances?
Using an SDB has dramatically affected the quality/reliability of my code.
Of course, so has function prototyping, just not to the same extent.
Marcus 🙂
Marcus,
I would argue that much of what you are using the debugger for is better
checked in the design phase. Do you really check out every line of code
you write in the debugger? Do you check all possible conditions and
parameter values in the debugger? Sounds kind of brute force to me.
— Mike Roth
Just to make a point, I have NEVER said that debuggers don't have value and
aren't very useful tools. I just feel that people tend to rely on them too
much. "When all you've got is a hammer, everything starts to look like
nails."
— Mike Roth
Mike,
I don't check ALL values, etc. I do change boundary range conditions, etc.,
and I do a LOT of front end design work before I write any code.
Unfortunately, I make typos, make a few improper assumptions, etc. when I
am designing a program. You see, I work with data that a CLIENT produces,
not me. Sometimes a client can inject unimaginable data into an otherwise
sane data stream. I just can't anticipate everything. Can you? I came from
the environment where I had to use printf's to find bugs. Please don't tell
me that "proper" design will always catch wild pointers, etc. One typo, and
you might be sunk. Also, what about enhancement/maintenance of a program?
What happens when your data stream changes without notice, and you can't
seem to determine how it has changed? An SDB has saved countless hours
looking for these problems. I still use prototyping, though. I won't argue
that.
Marcus :^{
Hmmm, I thought C had more protection in it than allowing a 'typo' to
de-reference the wrong kind of pointer. If not, mayhaps we should all
re-evaluate our naming conventions….so that typos cause compiler errors.
Hmmm… haven't you ever keyed 100 when you meant 10, or 1000. About 5
years ago I worked on a project that turned into about 5.5 million lines of
C code. Believe me, with THAT much typing going on, someone is going to
type in incorrect constant (I know, you #define everthing, right? So do you
write "for (x=ZERO; x<MAX_VALUE; X+=ONE)" ? I hope not). I know, good front
end design eliminates 99% of those awful bugs I mention, but what do you do
with that remaining 1% :^) By the way, I think MAX_VALUE is ok, just not
ONE and ZERO :^)
That loop isn't gonna run very well…unless you have a: #define X x or
some such equivalent in the program either. Yeah, that's one of the
reasons I like C as much as I do……cAsE SeNsItIvItY…..wonder why I
hadn't thought of that before <grin>
Gee… did I type 'x' in upper case? See what I mean about those typos
<grin>.
Marcus :^{
Yeah, you did. But any good compiler would complain about an undefined
variable…unless _you're_ one of those who likes to use names with the
same spelling, but different CaPitAlIzaTIon.
Victor A. Wagner, Jr.
No, no, no! I still wonder about the sanity of "struct gfxbase *gfxbase;"
:^) I do use procedure names such as "NextFieldValue" as opposed to
"next_field_value" just to save space (so shoot me). However, I would never
use "FieldDef" and "FIELDDEF" in the same program, YIKES! I use several
different text editors each day, and I can't seem to remember which ones
default to case sensitive searches. One little trick I do employ though, I
always call routines with the open paren next to the function name, i.e. –
MyFunction(args). When I write the function, I always put a space between
the function name and the open paren, i.e. – MyFunction (args). If I need
to do a grep or whatever (we'er talking about one module out of hundreds)
to locate the source file of the function, I can use quotes and specify the
paren with a space, such as grep "MyFunction (" *.c. This can be quicker
than looking the function up in the docs, especially when the function
isn't modified/used much (too bad PeeCee's have such limited naming
conventions for files :^)
Marcus