Shotgun Debugging
One of the most painful things I experience with the students I tutor is the practice of Shotgun Debugging. The practice will generally give the student horrible, unreadable code. After today’s tutoring, I determined it was time to write about some common debugging practices. So, here are the things I tell my students every week - and they quickly forget.
Only change one thing at a time.
This one is hard for beginning programmers. They get a logic error (or sometimes even a compile error) and then change 5-6 things in their code before they try again. If the changes work, they have no idea why, and will change 5-6 things next time they get a similar error. Which leads me to the next point:
Learn what the common errors mean.
….and how to fix them. When you get the error in Java for “cannot find symbol”, what does that really mean? Look at the text associated with it! It will tell you if it doesn’t understand the class you are looking for, or the variable, or even the method. Got a “null pointer”? That really does mean that something you are referencing is null! The JVM does not lie! Sure, some errors are a little more complicated, for those:
Actually read the error.
The biggest problem I see with students is they simply do not understand the code that they are working with. Reading the errors and understanding what is actually happening when you manipulate a line or two of code is the first step in becoming a better programmer. Every good programmer has spent a significant amount of their time learning how to debug, not just how to code. Lastly, I find myself telling my students:
Make sure you catch every instance of the error.
Let’s face it. We try to teach reusable, generic code, but it just doesn’t happen. I have learned to accept that some students are just going to copy and paste branches of code, over, and over, and over again. So, if you must do this, when you realize there is a logic error in the branch you copied, it will exist in every branch… no matter how much you think you “just fixed it”.
Sometimes tutoring can be very frustrating, but I really do enjoy the moment when a student finally has it click. I suppose there is nothing I can do sometimes, because some students just really hate code, but I hope that they can at least take a little bit back from what I help them with.
excellent advice!! i was stubborn when i first started learning how to program. sadly, it took me a long time to realize that the errors actually were pretty telling of what and where the error was! i think we’re so used to getting cryptic error messages (esp. from Windows!) that we’ve become pretty conditioned to ignore them. c’mon now, a compiler that could actually give useful error messages?! nonsense!
now C/C++ is a completely different story…
Was I really that difficult to tutor? LOL
“Sometimes tutoring can be very frustrating, but I really do enjoy the moment when a student finally has it click.”
Please, help me make it “click.”
Solid tips on debugging. It’s really not that hard if you take the time to read the message.
Java makes it frighteningly easy and I’m amazed when people just don’t take the time to read the error message. They usually provide a line number and an error. Just play detective and back trace through what happened. If you wrote the code you should have a general idea of what you were trying to accomplish.
C/C++ isn’t as bad as everyone makes it seem. You just need to have a solid grasp of what you can do. And you have to understand that errors can propagate. Start with the first error and work up a bit.
What it comes down to, is a learning process. You get better at programming/debugging from running into all the errors and fixing them. Then you learn not to make that mistake again.