Print Statements: My Favorite Lazy Debugging Trick
Okay so here's the thing. You've written enough code now that stuff has probably broken on you. Not "the program crashed with a big red error" broken. The worse kind. The kind where it runs just fine and gives you the wrong answer, quiet as anything, and you have no idea why.
That's the debugging you're going to do most as a beginner. Not typos, those at least yell at you. It's the silent wrong stuff. And my favorite tool for hunting that down costs nothing, takes ten seconds, and my son thinks it's embarrassing.
The caveman method
Jared watched me debug something a while back and said, "oh, you're using print statements like a caveman." He wasn't wrong. That is exactly what I was doing. I still do it. It works.
Here's the idea. When you don't know what your program is doing at some point in the middle, you just ask it. You stick in a line like:
``python print("here") ``
or better,
``python print("total is:", total) ``
right in the middle of your code, run it, and read what comes out. Now you know what the computer actually thinks total is at that moment, instead of guessing.
That's it. That's the whole trick. There are fancy debugger tools built into real code editors that let you pause the program and poke around, and those are genuinely useful once you're doing bigger stuff. But for most of what you'll write in this class, a print statement gets you the answer faster than setting all that up. Super simple, super effective, and nobody's grading you on how professional your debugging looks.
A worked example
Say you've got this:
```python price = 12 quantity = 3 tax = 0.07
total = price + quantity * tax print("Your total is", total) ```
Run it. You'll get something like Your total is 12.21, and if you're paying attention, that should feel wrong. Twelve dollars, times three, plus tax, should be way more than twelve twenty-one.
Instead of staring at the whole thing trying to spot the problem by squinting, add a print statement right after each piece:
```python price = 12 quantity = 3 tax = 0.07
subtotal = price * quantity print("subtotal is:", subtotal)
total = subtotal + subtotal * tax print("total is:", total) ```
Now when you run it, you can see subtotal show up as 36, which is correct, and then watch total come out right too. The bug in the first version was order of operations, quantity got multiplied by tax instead of price times quantity first. But you don't have to be a math wizard to catch that. You just have to be willing to print things out at each step and read them like a person, not assume the computer's doing what you meant.
Why this works better than staring
When code breaks, the instinct is to reread the whole thing top to bottom, over and over, hoping the bug jumps out. It rarely does. Your eyes skip over the same mistake every time because you already know what you meant to write.
Printing forces the computer to tell you what it actually has, not what you assumed it has. That's the whole value. You're not smarter than the bug by staring harder. You're smarter than the bug by asking it questions.
I do this constantly, at every stage, not just as a beginner thing. Figuring out why the computer hates me today usually starts with three or four print statements scattered through the code like tripwires, then reading the output line by line until something looks off.
One habit that'll save you grief later
Write your prints boring. I mean this. Early on I got really proud of a slick one-line fix I'd written, showed it to Jared like I'd done something clever, and then came back to that same code a week later and could not for the life of me figure out what it was doing. My own code. A week old.
Clever is not the goal. Clear is the goal. Same goes for your debug prints, don't just write print(x) fifteen times in a row and then try to remember which one was which. Label them:
``python print("DEBUG - price:", price) print("DEBUG - quantity:", quantity) ``
That "DEBUG" tag also makes it easy to find and delete them later, which you should do once things are working. Nothing wrong with leaving a stray print in while you're figuring things out, but a finished program shouldn't be full of leftover debug lines confusing the next person who reads it. Even if the next person is future-you.
Try this at home
Take any small program you've already written, the grocery total one is perfect for this, and deliberately break something. Swap a plus for a minus, mistype a variable name, whatever. Then use print statements to hunt down what changed, without just eyeballing the code. Get comfortable asking the program what it's thinking instead of guessing.
Before next time: keep your grocery-total program handy, we're going to make it smarter next lesson and print statements will probably save you at least once while you're at it.