Debugging

Code Inspection

• Read through the code you have written. Be thorough

  • Dry run it in your head before you execute the code

  • One of the cheapest approaches (in terms of your time)

  • But does rely on experience (you get better with practice)

• Start at the beginning of the method where the program goes wrong

  • Another good reason to keep your code modular

• If you can’t see anything obvious after about 3-5 minutes, then stop and move on to a more systematic approach

Know when you are Data Deficient

• If you can’t find a bug by code inspection, then you don’t have enough knowledge to fix it 

  • Stop trying to fix the problem

  • Start trying to identify the problem 

• Start logging diagnostic data about your program

  • Use printf() 

  • Entry/exit of methods, loops, conditionals

• Output the value of key variables: parameters, loop conditions, return values…

• If your code is complex, consider making debug code more permanent so it can be reused whenever you need it

Runtime Debuggers

• Debuggers allow you to visualize what your program is doing

  • See each line of code being executed in real-time 

  • See the values change variables as your program is running

  • VS Code has a great debugger… Install the C++ extensions

  • Programs normally run much too fast for humans to observe

  • Breakpoints can be added to programs 

  • Breakpoints pause the program in the debugger when a specified line of code is reached. You can have many breakpoints at the same time

Reproducibility

• Some bugs are transient 

  • Never ignore them and hope they don’t come back. They will

• Stop trying to fix the problem

  • Focus on creating a reproducible test case

  • Document everything you do 

  • Github issues are perfect for this

Thinking Outside the Box

• There are many external factors that can cause problems

  • Is the file you are editing the same as the one you are testing? 

  • Have you compiled all your C++ files? Are there any files missing?

  • Case sensitivity is important in most languages

  • But some file systems are not case sensitive e.g. Windows… 

  • Did you know your H: drive is a Windows file system?

  • Time can even be a factor. Some of the hardest bugs to fix relate to temporal anomalies

  • Are you providing the same data input to your program?

  • In the same order?

Rubber Duck Debugging

• Explaining the problem and code to yourself out loud 

  • Duck can be a real duck (or any inanimate object) that you talk to

  • The act of talking about it often helps your brain think differently

• But be aware that you will have unconscious bias

  • If you wrote your code then you will likely think it is correct

• Talk the behaviour through with another developer in your team

Divide and Conquer - Space and Time

• Reduce the places where the bug can hide

  • Create a minimal reproducible to test case

  • Remove as much unnecessary code as possible, whilst still demonstrating the bug

  • Review GitHub commits from you and your team

  • Identify changes to relevant parts of the codebase

  • Revert to an earlier version of the code. Isolate which commit introduced the bug

  • Look at the diff from that commit

Typical Debugging Workflow