No, I think it is important to acknowledge the temptation and
usage, and develop the habit of writing code in such a manner that
the compiler can find the problems. This means, to me, such things
as "if (CONST == expression)", short single purpose functions,
observing the rule of 7, careful formatting, and who knows what
else. It also means lint early and often.
No, that won't do it. I'm talking about bugs in the algorithm (or in
the translation of it into C), where the compiler can't catch them
because what you write is syntactically valid, it just doesn't make
sense for what you are trying to do.
char *my_strcpy(char *dest, const char *source)
{
while (*source)
*dest++ = *source;
return dest;
}
Compile and lint might find typos, but only looking at it (or running it
and finding that it fails, probably catastrophically) can find the
actual error. If there were a typo in it which caused it to fail
compilation then /at least/ it would mean that the programmer looked at
it again and is thus more likely to spot the bug.
I tend to compile after about two lines of revised code. Maybe
less.
Well, that's pretty useless when writing the code initially, the code is
very unlikely to compile at all. Or if the code being revised is in s
common header file so that it causes the whole project to be recompiled
each time. Although that would be a nice job if that were company
policy -- change two lines, recompile which takes half an hour, come
back and chance another two lines, have another half hour break while it
recompiles everything again...
Chris C