Context:

There's something you don't understand about your code. (Typically you don't understand its behavior ... it's doing what you told it, but not what you want.-) You can try to match your mental model of the code to the code itself, but you may fail, or you may fail to do it quickly.

'''Therefore:'''

Ask the code. Set a breakpoint and find what the value really is. Set a breakpoint (or two) and find what the flow of control really is. Set a breakpoint and find how (and if!) the program gets somewhere. Maybe don't set a breakpoint, just type some code into your debugger and run it.

Known uses:

ExtremeProgramming in the ChryslerComprehensiveCompensation project.
See
http://www.XProgramming.com/Practices/PracLetSmalltalkTellYou.html
and
http://www.XProgramming.com/Practices/PracJustSetTheHalt.html
----
The best way to ask the code is build a unit test case.  The first iteration will fail because you don't know what the result will be.  Once you get a value back, you need to think about if it's the right thing or not.  When you're finished, you have a test that shows exactly what the code does.

----

Also Known As:

"Star Wars Consult" and "The Jedi Way"
(in the immortal words of Obi-Wan Kenobi: ''"UseTheSourceLuke!"'')

-- BradAppleton

----

'''By Using the Debugger'''

I've been applying this to my own work in Perl and C++.
(It's easier in Perl, where the containers are more visible to the debugger,
and I can type more code in the debugger).

Heh. I just spent an hour trying to ask the [C++] code, "How is this variable initialized?" I just realized; the code's inability to answer ... was an answer. (The variable needed to be zero, and had been; until I changed from a global variable, where all fields are guaranteed to start as zero, to a dynamically allocated variable, where they aren't.)

At that point, the student achieved enlightenment.-)  --PaulChisholm

----

Also related to DebuggingAndTheScientificMethod.  As Donald E. Knuth ''(DonKnuth)''
supposedly once said:

''Beware of bugs in the above code; I have only proved it correct, not tried it.''

--ScottJohnston

''I was curious about this and looked on Knuth's web page. He writes [http://www-cs-staff.stanford.edu/~uno/news98.html]: "More than a hundred webpages ascribe that quote to me, and it sounds like something I might well have said. But lately people have been asking me for the authentic source, and I've totally forgotten where I wrote it. Probably not in a published paper, since I've written few papers in the first person that include untried code. My best guess is that it was in a letter I sent to somebody. So if you were that somebody, or if you have any other clues about the source of that line, please let me know."''

He got an answer: see http://www-cs-staff.stanford.edu/~knuth/faq.html. --DanSchmidt

----

This is a bad practice to rely on. It has it's place of course, but coding with the debugger often leads to bad code. The reasoning (in my experience) is you don't understand the flow of your code for any case except for the path the debugger shows you.

When I come across a problem I try to follow the code thru in my head. Mentally debugging if that makes sense. Often I will catch the bug immediately. Only if that doesn't work do I AskTheCode . GarethLewin

----

'''By Other Means'''

This principle applies outside of software, too.  In HowBuildingsLearn,
StewartBrand quotes an MIT animal physiologist who told his students:

The animal is always right.  When in doubt, ask the animal.

-- EugeneWallingford

That could be extended rather poorly to:

I am always right. If you doubt that, just ask me.

----

Is this the same as AskTheComputer?

''It is closely related to AskTheComputer, but AskTheCode focuses on looking at the source code, while AskTheComputer is about looking at the results of execution.''

----

''Another way to AskTheCode is to search it (with grep or an equivalent)''

----
CategoryQuote