Debugging for beginners

Nobody's perfect, and neither is your code, but that's OK

I discussed one thing that developers hate last time around — commenting — so I thought I’d follow up with another big source of developer frustration: Debugging.

Bugs happen. Every developer in the history of programming has had to debug, even the legendary ones who write code with butterflies. Becoming a skilled programmer doesn’t mean never making errors, it means becoming better at finding and fixing errors. When you’re starting out, your programs will likely be small enough that you may be able to figure out the problem by taking a closer look at your code, paying attention to the syntax, and tracing the execution process in your head. Once you get beyond that initial stage, though, you’ll need some help to find the bugs.

Let the IDE Do the Work

When I talked about IDEs, and when I mentioned choosing your first language, I discussed the role that a good IDE plays in debugging. Most IDEs will report compiler errors to you, sometimes providing clarification about what the errors mean, and will usually take you to the line of code where the error was found — which isn’t always the right spot. If you declared a variable as an int, and later try to assign a float value to it, the IDE might point to the assignment as the source of the error, when it’s actually the variable declaration that you need to fix.

More valuable than the IDE’s error features are breakpoints and the ability to step through code. Even the most basic IDEs will allow you to run your code and stop it at a specific point, before the execution completes. Most IDEs will allow you to inspect the data at that point in the program, which is usually helpful in determining where the problem is. If you have an idea of what the value of a variable is supposed to be at a given point, you can know whether the bug is found before or after that point in the code.

Or Make The Code Report to You

Even without IDE support, you can still check the value of a variable or function while your program is running. Just about every language has a function for printing a message to the console, or to a log file, and you can use that to get data while debugging. Want to know what the value of count is during a loop? Print it to the console. Worried that a certain function is never getting called? Insert a line in the function so that it logs a message when it’s called. Exactly how you do this depends on the language, but you can make the tools of the language work for you.

Know the Common Errors

No matter what language you’re programming in, there are errors that are common for beginners to make. In C++, one of the most common is using an assignment statement: x = y when you meant to test for equality: x == y.

In languages that use braces {} to set off blocks of code, misplacing an opening or closing brace is a common error. This is another area where the IDE can help, by keeping track of your braces or highlighting them when you close a block. Languages that use lots of parentheses have similar issues (hello, Lisp fans!). Forgetting the single or double quotes around strings is another common related error.

Naming conventions for variables or functions can be a post by themselves, but whatever convention you use, be sure to stick with it. Typos can trip you up, but even inconsistent capitalization can cause problems. Many languages will draw a distinction between myLovelyVariable and myLovelyvariable, so be sure to watch out for naming errors.

On a similar note, if your language of choice is strongly typed, be careful with those types. Don’t try to assign a floating-point number to a variable declared as an integer, for example. Be especially careful with Boolean values; in some languages, any value other than zero reads as true, which could lead to headaches if you pass an integer to a function that’s expecting a Boolean.

If your language allows importing or requiring libraries in other files, make sure to use the proper import statement to include them in your file. You don’t want to spend hours trying to figure out why a function won’t work, when the problem is that the compiler doesn’t know about it.

If you can find out the common errors in your language of choice, you’ll have an advantage in looking for them in your own code. A quick Google search on “common syntax errors,” plus the language of your choice, will turn up plenty of hits with good advice.

Don’t Be Afraid to Ask

The most frustrating part of debugging is knowing that it’s a skill that comes with experience. When you’re a novice, you’re perfectly aware that you probably made a completely obvious mistake, one that an experienced developer could find and fix in moments. But because you don’t know enough yet, you can’t do that. Instead of beating your head against the code for hours, find somebody more experienced to help you out. If you’re learning in a classroom environment, that could be the instructor or another student. In a professional environment, see if you can find a mentor. If you’re learning from a book or video, see if the author or publisher has a site with a forum where you can ask questions. Even if you’re just learning completely on your own by picking bits and pieces from the web, you can still find community forums for almost any language you can name, and there’s always sites like Stack Overflow. There are people out there willing to help, but first you have to get over the fear of asking a stupid question. There are three possibilities:

  • The problem is related to something you haven’t learned yet, so there’s no way you could have found it on your own. Now you know a little more than you did before — at the least, you’ll know what area to learn next.
  • The problem is completely new and original, and even an instructor or mentor will have difficulty figuring it out. Congratulations! You’ll learn something by figuring it out together.
  • The problem really is something basic, like the x == y issue I mentioned earlier, and maybe you could have spotted it for yourself, given enough time. You’ve still learned something — you’ve got a bit more experience spotting that problem, and you’ll be better able to look for it next time.

No matter how the situation comes out, you’ve learned something new.

Finally, this article wouldn’t be complete without a mention of Rear Admiral Grace Murray Hopper, the original debugger. If you don’t know the story, it’s worth a read.

tags: , ,

Get the O’Reilly Data Newsletter

Stay informed. Receive weekly insight from industry insiders.

Get the O’Reilly Web Ops and Performance Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

Get the O’Reilly Hardware Newsletter

Get weekly insight and knowledge on how to design, prototype, manufacture, and market great connected devices.

Get Four Short Links in Your Inbox

Sign up to receive Nat’s eclectic collection of curated links every weekday.

Get the O’Reilly Design Newsletter

Stay informed. Receive weekly insight from industry insiders.

Get the O’Reilly Web Platform Newsletter

Stay informed. Receive weekly insight from industry insiders—plus exclusive content and offers.