Re: How do you debug?
On Oct 3, 8:28 pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
On Oct 3, 6:57 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
Puppet_Sock a =E9crit :
On Oct 2, 4:56 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
[snip]
Actually, keeping asserts in the release code (i.e. not using NDEBUG=
) is
a good idea; just like wearing a safety belt after you have learned =
how
to drive.
You will find a lot of people who disagree with that.
Certainly there are many situations where it is just
unacceptable.
I work on an aeronautic embedded system with real time and
fault tolerant cobstraints. It is pretty critical and I can
tell you the asserts are still in the code when it takes
off.
I'm a nuke. If one of the control computers did an
assert, the operator would come and find me. This
would not end well.
You mean he would prefer you to stumble on, not knowing the
internal state of the program, and behave in an undefined
manner, maybe causing a nuclear meltdown.
The very first rule in all critical systems is if there is the
slightest doubt about the program, abort and get the heck out of
there, so that the redundant back-up systems can take over.
I don't think you mean the same thing by "assert"
that I do. When a program hits an assert and fails,
the program stops. All over, bang, goodbye, only
way to get it back is to restart the program.
This is something you put in your aircraft?
It's certainly something that is in the control systems on an
Airbus (or was when I consulted there, in the late 1970's). It
was a contractual requirement when I did a locomotive brake
system, in the mid 1980's---in fact, any time there was any
doubt concerning the reliability of the system, they cut the
power supply to it.
[...]
I rarely use the debugger except as post mortem analysis;
my unit tests are usually sufficient.
Again, you will get many people who disagree with that.
Indeed, my advice is to *always* step through every line
of code in the debugger, at least once.
What for ?
I'm just guessing, but what I'm guessing is that you are
a bigtime Unix coder.
Which "you"? I've worked on many different types of systems,
from 8 bit embedded processors with 2 KBytes ROM, to IBM
mainframes.
You step through your code to catch stupid mistakes.
Except that stepping through the code doesn't necessarily catch
all, or even most stupid mistakes. You use code review to catch
stupid (and not so stupid) mistakes. And you use extensive
tests to catch problems in your code review process.
I've seen this lots of times where guys put code back into the
codebase without ever stepping through it.
In most places I've worked, at least since the late 1980's, the
version control system was set up so that you couldn't check in
code without it having passed its unit tests. And the unit
tests were reviewed, along with the code, to ensure coverage.
In some places, at least, checked-in code was quarentined until
someone cleared it, ensuring that it had passed code review.
The review process is critical. At least some of the reviewers
must be relatively unfamiliar with your code, to bring a fresh
view of it. Nothing you, or anyone who worked closely with you
during the development phase, can do will replace this.
[...]
I've also had the case where the coder refused to believe
there was anything wrong with his code till I fired it
up in the debugger and showed him the bad behaviour.
If the code review panel says that the code is wrong, it is
wrong. The programmer either fixes it, or is fired.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34