On Bugs

• The aim of this explanation💡 is the treatment of bugs based on my own experience as well as capturing Lecture 11: Testing and Debugging from Introduction to Computer Science and Programming @ MIT OpenCourseWare

1. Show up with time

• Mostly true for own scripts that do not have an extensive test coverage
• Give code some time within the usage
• And wait for bugs to come to light

2. Don’t live alone

• They usually appear in groups
• If you find a bug, there is probably more of them

Typically, even though they don’t breed, there are many bugs. And keep in mind that the goal of debugging is not to eliminate one bug. The goal is to move towards a bug-free program. I emphasize this because it often leads to a different debugging strategy. People can get hung up on the sort of hunting these things down, and stamping them out, one at a time. And it’s a little bit like playing Whack-a-Mole Right? They keep jumping up at you. So the goal is to figure out a way to stamp them all out.

3. Bugs don’t crawl into programs

If there is a bug in the program, it’s there for only one reason. You put it there. i.e. you made a mistake. So we like to call them bugs because it doesn’t make us feel stupid. But in fact, a better word would be a mistake.

4. Bugs don’t breed

If there are multiple bugs in the program, it’s because you made multiple mistakes. Not because you made one or two and they mated and produced many more bugs. It doesn’t work that way. That’s a good thing.

5. Read, don’t just single-step

The two best debugging tools are the same now that they have almost always been. They are 1) the print statement 2) reading.

• There is no substitute for reading your code.
• Getting good at this is probably the single most important skill for debugging.
• And people are often resistant to that.
• They’d rather single step it using a debugger than just read it and try and figure things out

6. Be systemati

• Being systematic — that’s what distinguishes good debuggers from bad debuggers.
• Good debuggers have evolved a way of systematically hunting for the bugs.
• And what they’re doing as they hunt? Reduce the search space.
• Aim: localize the source of the problem.
• Debugging is a search process.

So when searching a list to see whether it has an element, you don’t randomly probe the list, hoping to find whether or not it’s there. You find some way of systematically going through the list. Yet, I often see people, when they’re debugging, proceeding at what, to me, looks almost like a random fashion of looking for the bug. That is a problem that may not terminate.

7. Ask: Why this result

• First, seek to understand!
• Don’t ask why not expected result
• Ask why this (wrong) result

8. Ask: is my syntax correct

• e.g. when calling a function in PowerShell, are you still not stuck with Python’s syntax

9. Ask: is this part of the family

• Are there similar errors in multiple places

10. Ask: how to fix this

11. list used sources

• MIT 6–00-introduction-to-computer-science-and-programming-fall-2008-lecture11

Originally published at http://pavol.kutaj.com on February 12, 2021.