mnemonic

[Eric Sosman]

[...]
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan
This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]

The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.

Depends on your familiarity with the code and how well you know how to use
a debugger. Some people are just good at it - binary chop and gut
instinct.

Debuggers are vastly overrated. They are sometimes useful
when you have little idea of what's going on and don't know where
to look, but all they can really do is provide grist for the
reasoning mill. In many "interesting" scenarios, debuggers
distort the progress of the program so much that they are of
scant use. Reasoning wins almost every time. IMHO.

<OT> I've seen some snippets of articles on debuggers for
"reversible" languages, where computations can be run backwards
to restore the status quo ante. This seems a potentially more
useful sort of tool, but most programming languages lack the
property of reversibility. C, for example, has the assignment
operator, which obliterates the prior contents of the assigned
object and is thus irreversible. Transaction journals could
remedy that problem, but at an obscene run-time cost. </OT>

In any case, the facts of the experiment remain: The people
who saw the comments did worse than those who didn't. Unless
you have reason to believe that the commented crowd were drawn
from a less able population, Occam suggests that the comments
themselves impeded the progress of debugging.

 

[Richard]

Richard wrote:
[...]
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan
This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]
The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.

Depends on your familiarity with the code and how well you know how to use
a debugger. Some people are just good at it - binary chop and gut
instinct.

Debuggers are vastly overrated. They are sometimes useful
when you have little idea of what's going on and don't know where
to look, but all they can really do is provide grist for the
reasoning mill. In many "interesting" scenarios, debuggers
distort the progress of the program so much that they are of

How do they distort the progress? They distort it much less than adding
printfs!

scant use. Reasoning wins almost every time. IMHO.

I disagree 100% with most of the above. They are very useful when you
use them in a properly structured manner. It is almost impossible to
"deduce" error conditions in a huge code base where the bugs occur 23
hours into execution for example.

In the real world people maintain SW who never wrote an original
function in that code.

The debugger is invaluable in stepping through with live data and
demonstrating the call flows. That in conjuction with a profile of
course.

You make it sound like using a debugger is replacement for
"reasoning". it isn't of course. It is a utility to utilise your
reasoning and to check the program at crucial error prone times.

<OT> I've seen some snippets of articles on debuggers for
"reversible" languages, where computations can be run backwards
to restore the status quo ante. This seems a potentially more
useful sort of tool, but most programming languages lack the
property of reversibility. C, for example, has the assignment

Call stack at the point of the crash. Almost as good.

operator, which obliterates the prior contents of the assigned
object and is thus irreversible. Transaction journals could
remedy that problem, but at an obscene run-time cost. </OT>

In any case, the facts of the experiment remain: The people
who saw the comments did worse than those who didn't. Unless
you have reason to believe that the commented crowd were drawn
from a less able population, Occam suggests that the comments
themselves impeded the progress of debugging.

I'm not sure what you mean by "commented" - where did this come from?


Note : of course it is better to get it right first time. But in the
real world there will always be bugs.

2nd note : if a system crashes I can guarantee that i can debug it to
the point of the crash quicker than you can read and understand 500000
lines of C code and run it through in your head with all possible data
input and come to a guess at where it might crash .....

 

[Eric Sosman]

Richard wrote:
[...]
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan
This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]
The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.
Depends on your familiarity with the code and how well you know how to use
a debugger. Some people are just good at it - binary chop and gut
instinct.

Debuggers are vastly overrated. They are sometimes useful
when you have little idea of what's going on and don't know where
to look, but all they can really do is provide grist for the
reasoning mill. In many "interesting" scenarios, debuggers
distort the progress of the program so much that they are of

How do they distort the progress? They distort it much less than adding
printfs!

<OT> Never debugged a multi-threaded program? </OT> Never
seen a program that misbehaves when run on its own but runs
fine and produces correct results when run under a debugger?
Never seen a timing-dependent program that goes completely
blooey when a breakpoint retards its progress? "You are young.
Life has been kind to you. You will learn." -- S. Todd

I disagree 100% with most of the above. They are very useful when you
use them in a properly structured manner. It is almost impossible to
"deduce" error conditions in a huge code base where the bugs occur 23
hours into execution for example.

Please tell us about the last time you sat in front of a
debugger's screen for twenty-three hours, and then had any
semblance of a neuron still firing when the bug finally struck.
If, that is, you were lucky enough to have put your breakpoints
in useful places.

In the real world people maintain SW who never wrote an original
function in that code.

The debugger is invaluable in stepping through with live data and
demonstrating the call flows. That in conjuction with a profile of
course.

You make it sound like using a debugger is replacement for
"reasoning". it isn't of course. It is a utility to utilise your
reasoning and to check the program at crucial error prone times.

I said a debugger could only provide "grist for the reasoning
mill," and I stand by it. With the debugger you may observe that
variable `x' is mysteriously set to 42, and this is what eventually
causes the program to print the ten million dollar water bill.
But the 42 is clearly a symptom of something unidentified that
has already gone wrong, and you need to reason about that earlier
fault. At a minimum, you need to reason about where to set the
breakpoints for your next twenty-three-hour run.

Call stack at the point of the crash. Almost as good.

Nowhere near as good. Back to that mysterious 42: The great
question is "Hunh? How did *that* happen?" With a call stack
(a static snapshot, somewhat less informative than a core dump)
you are completely on your own. With a reversible program you
could back-step until you see the 42 revert to something more
reasonable, then see that the bad `x' really derives from a
bad `y' elsewhere, and then back-step to find where `y' got
polluted. Or let that issue go for a bit, stuff a good value
into `y' and forward-step again, this time along a different
path ... No, Richard, a call stack cannot do this.

I'm not sure what you mean by "commented" - where did this come from?

From the experiment I described, above, in the part you seem
to have read with little attention.

Note : of course it is better to get it right first time. But in the
real world there will always be bugs.

2nd note : if a system crashes I can guarantee that i can debug it to
the point of the crash quicker than you can read and understand 500000
lines of C code and run it through in your head with all possible data
input and come to a guess at where it might crash .....

A program that crashes is a blessing to the programmer who
is trying to debug it. A program that runs successfully all the
way to completion but prints the ten million dollar water bill
along the way, or a program that runs for twenty-three hours
when you needed it to complete in eighteen -- those are the
problems that the grownups tackle.

 

[aarklon]

woopsie!

your "sweetened drink" should be "drink sweetened" to make the pi value
come out correctly

Tim

Okay that's correct ,I quote wrongly

 

[CBFalconer]

.... snip ...

In any case, the facts of the experiment remain: The people
who saw the comments did worse than those who didn't. Unless
you have reason to believe that the commented crowd were drawn
from a less able population, Occam suggests that the comments
themselves impeded the progress of debugging.

I suspect that this experience reflects more on the quality of the
original comments than on the general usefulness of comments. One
thing that should normally be done is a comment per function,
describing the general action of the function. This should be
unchanged with revisions. (If it needs changing the function needs
rewriting).

After that comment is in place (which would normally precede
writing the function guts) the internal operation can be commented
as appropriate.

This attitude is language independant.

 

[Mark Bluemel]

Okay that's correct ,I quote wrongly

So it wasn't that good (or that simple) a mnemonic was it?

Case proven mi'lud. Mnemonics aren't that much help.

 

[Chris Dollin]

or is there any simple mnemonic such as

"How I want a sweetened drink

drink, alcoholic

of course after the heavy lectures
chapters

involving quantum mechanics" which is mainly used by math pros for
remembering Pi value(3.14195265358979)

At least that's my recollection, and I attribute it to Sir James Jeans.

(fx:google) I still attribute (and spell) it so.

 

[aarklon]

So it wasn't that good (or that simple) a mnemonic was it?

Case proven mi'lud. Mnemonics aren't that much help.

i don't agree with you. mnemonics in some instances are helpful

ex:- the famous mnemonic for remembering resistor color codes

"Bad Boys Rape Our Young Girls, But Violet Gives Willingly."
"Cute White Babes Loves Hairy Dogs"
"Please Excuse My Dear Aunt Sally "
"Please Do Not Throw Sausage Pizza Away"

see:-

http://www.ict4us.com/mnemonics/en_networknames.htm
http://en.wikiquote.org/wiki/English_computing_mnemonics
http://www.mnemonic-device.eu


http://en.wikiquote.org/wiki/English_electrical_and_electronic_mnemonics
http://en.wikiquote.org/wiki/English_mathematics_mnemonics

http://en.wikiquote.org/wiki/Weights_and_measures_mnemonics
http://en.wikiquote.org/wiki/English_spelling_mnemonics

 

[Al Balmer]

“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” – Brian W. Kernighan

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]

Richard seems to have missed the "if" clause in the above quote.

 

[Richard]

[...]
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.†– Brian W. Kernighan

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]

Richard seems to have missed the "if" clause in the above quote.

No. "Cleverly" means many different things and means different things
when coding than when debugging.

But this phrase is trotted out all the time to suggest that good
programmers dont need debuggers.

That interpretation of it is simply garbage.

 

[Flash Gordon]

Eric Sosman wrote, On 02/11/07 03:33:

Richard wrote:

Richard wrote:
[...]
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you
are, by
definition, not smart enough to debug it.†– Brian W. Kernighan
This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]
The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.
Depends on your familiarity with the code and how well you know how
to use
a debugger. Some people are just good at it - binary chop and gut
instinct.
Debuggers are vastly overrated. They are sometimes useful
when you have little idea of what's going on and don't know where
to look, but all they can really do is provide grist for the
reasoning mill. In many "interesting" scenarios, debuggers
distort the progress of the program so much that they are of

How do they distort the progress? They distort it much less than adding
printfs!

<OT> Never debugged a multi-threaded program? </OT> Never

I have.

seen a program that misbehaves when run on its own but runs
fine and produces correct results when run under a debugger?

I have.

Never seen a timing-dependent program that goes completely
blooey when a breakpoint retards its progress?

I have.

"You are young.
Life has been kind to you. You will learn." -- S. Todd

I'm not so sure the first two sentences apply to me any more, but I hope
the last still does. Life would get boring if I stopped learning.

Please tell us about the last time you sat in front of a
debugger's screen for twenty-three hours, and then had any
semblance of a neuron still firing when the bug finally struck.
If, that is, you were lucky enough to have put your breakpoints
in useful places.

Or you set breaks on a condition occurring rather than at a specific
location in the program then go home and come back in the morning.

I said a debugger could only provide "grist for the reasoning
mill," and I stand by it.
Agreed.

With the debugger you may observe that
variable `x' is mysteriously set to 42, and this is what eventually
causes the program to print the ten million dollar water bill.

With a decent debugger you can set a break on 42 being written to the
variable x if it static. If it isn't there are other methods you can use.

But the 42 is clearly a symptom of something unidentified that
has already gone wrong, and you need to reason about that earlier
fault.

Often you can look at the situation and reason something earlier to
break on.

At a minimum, you need to reason about where to set the
breakpoints for your next twenty-three-hour run.

Yes, you always need to think about what to break on. Sometime when
using a debugger I also add in some debug code to make it easier to find
the problem.

Nowhere near as good. Back to that mysterious 42: The great
question is "Hunh? How did *that* happen?" With a call stack
(a static snapshot, somewhat less informative than a core dump)
you are completely on your own. With a reversible program you
could back-step until you see the 42 revert to something more
reasonable, then see that the bad `x' really derives from a
bad `y' elsewhere, and then back-step to find where `y' got
polluted. Or let that issue go for a bit, stuff a good value
into `y' and forward-step again, this time along a different
path ... No, Richard, a call stack cannot do this.

It varies. Sometimes a call stack can point straight at the problem or
give you a strong indication of where to look. Sometimes it does not
give you any clue.

A program that crashes is a blessing to the programmer who
is trying to debug it. A program that runs successfully all the
way to completion but prints the ten million dollar water bill
along the way,

Debuggers can help in that. Stick in break points at various places
(possibly on the Nth time a given function is called) and check the
state until you find which part of the processing leads to an incorrect
result, then reason about that.

or a program that runs for twenty-three hours
when you needed it to complete in eighteen --

There a profiler will help. Another useful tool.

those are the
problems that the grownups tackle.

Grownups will use whatever tools will save them work in tacking the
problems.

Personally, if a program can be crashed reliably then the first thing I
reach for is the debugger since the state of the program when it crashes
can give me a starting point to reason from. If it does not help then it
does not cost much of my time (I don't watch whist it runs for 23 hours,
I get on with other stuff).

 

[Tor Rustad]

Richard wrote:

[...]

2nd note : if a system crashes I can guarantee that i can debug it to
the point of the crash quicker than you can read and understand 500000
lines of C code and run it through in your head with all possible data
input and come to a guess at where it might crash .....

I can guarantee you, on some systems others will find the bug faster
without a debugger, than you will.

Some of the C code I have written, "cannot" be debugged in production.
The binary is protected by hardware mechanisms, if a trigger goes off,
the current state of the program erased.

 

[Keith Thompson]

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. Especially when combined with HW break points and expression
watches.

I have debugged a LOT of large systems and fixed them without having the
need to understand the entire system.

You've commented on this quote before, and I suspect you may have
partially misunderstood it. I think that Kernighan uses the word
"debugging" to mean finding and fixing bugs, not necessarily to use a
source-level debugger; the latter is just one of many tools that can
be used. Adding printf calls or staring at hexadecimal core dumps is
"debugging" just as much as running, say, gdb is.

This is not intended as a comment on the virtues of source-level
debuggers, just a clarification of what Kernighan probably meant.

 

[Ben Bacarisse]

Is there any mnemonic for remembering C precedence rules????

Not that I know, but here are some thing that help me remember:

All the operators that "come after" bind the tightest. If you can't
remember this on it own, just think that a cast, despite being a very
high priority operator, can be used on a function call (or array
element) with no extra brackets: '(char *)function(...)'.

In maths, unary operators usually have high precedence and C follow
this. Thus all the prefix unary operators come next.

Most arithmetic tests don't need extra parentheses because the
relations (==, <, etc) bind more loosely than arithmetic.

Everyone know that * binds more tightly than +, so just remember that
&& and & are the Boolean and bit-wise analogues of multiplication
whereas || and | are the analogues of +. I.e. && binds tighter
than || and & beats |. (Many maths notations use AB or A×B to mean A
and B.)

Remembering that , is the lowest is also easy because , can replace ;
to turn a sequence into an expression (heck, it even looks like a
semicolon). It also mimics the way , behaves in a parameter list
(although of course *that* comma is quite another syntactic entity).

This covers the vast majority of common cases. I also like to
remember that you can assign a conditional ('index += up ? 1 : -1' is
my canonical example), but you can't shift by an arithmetic expression
('x >> (32 - bits)' requires the parentheses).

I hope this helps. The basic idea -- remembering what classic cases do
and do not need parentheses -- seems to me more valuable than rote
learning of the table.

 

[Keith Thompson]

Richard wrote:
[...]
ÒDebugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.Ó Ð Brian W. Kernighan

This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. [...]

Richard seems to have missed the "if" clause in the above quote.

No. "Cleverly" means many different things and means different things
when coding than when debugging.

But this phrase is trotted out all the time to suggest that good
programmers dont need debuggers.

That interpretation of it is simply garbage.

[...]

I don't recall anybody using the Kernighan quote to suggest that good
programmers don't need debuggers. (Some may have suggested that, but
I don't recall anyone using the quote to support that position.)
"Debugging" doesn't mean "using a debugger".

 

[Ben Pfaff]

Everyone know that * binds more tightly than +, so just remember that
&& and & are the Boolean and bit-wise analogues of multiplication
whereas || and | are the analogues of +. I.e. && binds tighter
than || and & beats |. (Many maths notations use AB or A×B to mean A
and B.)

Many programmers prefer to parenthesize uses of && and || that
appear in the same expression, to avoid needing to remember this.
This is what I usually do.

 

[Ben Pfaff]

"Debugging" doesn't mean "using a debugger".

I'd say that about half of my bugs I find with printf. Another
half, I find with valgrind. Another 5% are made obvious with
"git bisect". The last 10%, I find with a traditional debugger.

 

[Richard Heathfield]

Ben Pfaff said:

I'd say that about half of my bugs I find with printf. Another
half, I find with valgrind. Another 5% are made obvious with
"git bisect". The last 10%, I find with a traditional debugger.

Face down, nine edge first?

 

[jaysome]

Use parentheses and it's impossible to forget the precedence
rules.


I think I'll just stick to parens and not even try to remember that
mess of characters.

This is the best advice I've seen in this newsgroup in recent memory.

I've come across this type of ambiguous nonsense:

if ( msg->i.xtype & _IO_XTYPE_MASK != _IO_XTYPE_NONE )

It should have been written like this:

if ( (msg->i.xtype & _IO_XTYPE_MASK) != _IO_XTYPE_NONE )

Best regards

 

[Serve Lau]

In such cases, you'd probably be better off studying your code to see
why it appears so complex.

clear code and complex code are not opposites, if an expression gets too
many parentheses it just looks a bit weird to me. That doesnt mean I find
the expression complex. On top of that, I cant remember getting into trouble
understanding code on a single line/expression. (obfuscated contest code
doesnt count) Complex code has more to do with the total structure and
dependencies on each other.