| Date: | January 23, 2007 / year-entry #24 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070123-04/?p=28313 |
| Comments: | 21 |
| Summary: | This isn't psychic debugging, but it's the sort of dumb mistake everybody makes and which you can't see when re-reading your code because your brain shows you what you want to see, not what's really there. I'm trying to respond to the PSN_QUERYINITIALFOCUS notification, but it's not working. What am I doing wrong? INT_PTR CALLBACK... |
This isn't psychic debugging, but it's the sort of dumb mistake everybody makes and which you can't see when re-reading your code because your brain shows you what you want to see, not what's really there.
You can stare at this code for ages and completely overlook
that the wrong window handle is being passed to The correct code should read
SetWindowLongPtr(hdlg, DWLP_MSGRESULT,
(LPARAM)GetDlgItem(hdlg, IDC_MYCONTROL));
This phenomenon of missing the obvious because your brain shows you
what you want to see (rather than what's actually there)
reminds me of a time
one of my colleagues called me into his office to help figure
out why one of his loops was iterating only once.
He called the function up on the screen and talked me through it.
"Okay, now the variables are set up for the loop, so
I hesitatantly interrupted.
"Um, ' "Oops. Um, nevermind. Nothing to see here. Move along now." This is the same reason you want to have somebody else proofread your writing. Since you wrote it, your brain will show you what you meant to write, not necessarily what you actually wrote. |
Comments (21)
Comments are closed. |
I once wrote:
if (bSomething);
{
…
}
and had the entire team crowded around my desk trying to debug it.
I’ve done that!
The "if();" one, not the big complicated smart one. All of my coding errors are very, very stupid.
mis-spell default: in a switch statement. Like defualt:.
No whines, because it is a jump label…
I’ve lost count of the number of times I’ve made a dumb coding mistake, only to find it (or have it pointed out to me) when I dragged someone else in to help me find the bug.
It’s not even that I needed a second set of eyes sometimes – I just need to vocalize what I want the code to do and compare what I’m saying to what I’m seeing. Talking to yourself doesn’t always produce a coherent dialogue.
"Oops. Um, nevermind…"
That’s my personal motto.
s/hesitatantly/hesitantly/.
When I was a TA for a ‘Fortran for Engineers’ class, my favorite question from a student was: "Why is my ‘IF’ loop only executing once?"
"Oops. Um, nevermind. Nothing to see here. Move along now."
He really said that? I’m impressed. I never recover my poise that quickly when I goof up.
Doug: Many compilers can now warn of unused jump labels – something that’s saved me from that same thing.
>
That’s what you get when you use an uncivilised editor with no syntax highlighting.
In PHP a while ago I was working on a large OOP framework and in a class about halfway down the hierarchy, I did this:
public function __construct()
{
….
parent::__costruct();
}
(In PHP the parent constructor is not implicitly called if a child has a constructor defined.)
The results were so odd that it took me several hours to find the cause, and I probably read over that code at least a dozen times.
I do find sometimes it helps to actually read the code aloud. For me at least, it seems to force my brain to acknowledge what’s actually *on* the screen and not what I had intended to put there.
I once asked my fellow teammates: "My while loop is only running once, could you please help me?"
while (some-rather-long && complex-statement);
{
…
}
Ashamed when finding the extra semicolon? Nooo, not at all… :)
Sometimes One has to just vocalize it around:
Me: "Hi, what do you think of idea x, where you take A and B and… You’re right, B doesn’t belong there, it’s never gonna work, thanks."
Other guy: "Um… Glad to have been of assistance?"
Someone I used to work with, said that in a previous job they had a life-size cardboard cut-out of Superman and would go and ask him their questions, the act of asking ‘him’ the question would often mean they though of the solution.
Where can we get life-sized cutouts of Raymond Chen?
if() ; {
}
doesn’t tend to happen. This is one of several reasons why I prefer this bracing style, and avoid:
if()
blah;
Asking other people questions definitely helps. 90% of the time, when I go into a programming channel in IRC, I leave again without asking a question. The process of phrasing the question clearly, and stripping the problem down to a minimal case, finds my problem. In the remaining 10% of the time, either everyone is afk, or they don’t know the answer.
It’s called asking the janitor to help you fix your program. As you take baby steps walking through your code, the solution reveals itself. If there’s no janitor around, a neighboring colleague can help in a pinch, but might know too much.
I once spent an embarrassing amount of time trying to figure out…
if (SomeFunction)
DoWhatever();
…why SomeFunction was always returning true but my breakpoints in that function weren’t firing. It should’ve been blatantly obvious (and of course would have been if SomeFunction had taken arguments), but extended runs of 16 hour work days do weird things to the mind.
Similar to the spot you helped me out on the other week where I was passing wParam and lParam to DefWindowProc in the wrong order. The problem was much more interesting when I thought that DefWindowProc was handling WM_NCCREATE incorrectly. :)
This is one of the reasons that debugging at the assembly level is good – you can usually quickly spot errors in the source code (like using if (); or if instead of while) when you look at the disassembly.
Your brain can’t lie to you quite as easily when you move down to a lower level of abstraction :)
My favorite "stupid mistake" was writing something like
strcpy(buffer, "multiple null-terminated strings ");
It took hours of banging my head against the wall to track that one down.