We covered best practices for writing clean code, using compilers to catch bugs early, and writing good quality tests. However, you still have to find and fix bugs. Let’s face it, programming is hard. Algorithms and data structures are complex and thinking in advance of all possible edge and corner cases is very difficult. So your code will contain bugs. Typically, a developer spends half of the time finding and fixing bugs. You don’t want to be such a developer, you want to minimize the time you spend debugging. When trying to find bugs, you write print-statements in your code in order to figure out what your programme is doing, which statements are executed, what values of certain variables are.

And if you do it systematically, it works. However, it’s kind of time consuming and a bit error prone since you have to remove those print-statements later and you can introduce additional bugs doing that. So, using a debugger is actually a lot more efficient. For one thing, you don’t have to modify your source code in order to debug it. You can simply run your application step by step, statement by statement, and you can inspect the value of any variable at any given time. You can also run your code up to the point where a Boolean condition is satisfied or certain variable changes and then have a look around at what’s going on.

GDB and its advanced features will be discussed here as well as best practices which you can apply to any debugging tool. No doubt, you’ve come across the dreaded segmentation fault and you know that it’s notoriously difficult to pinpoint and fix the causes of that. Valgrind is a tool that helps you detect memory related problems and helps you fix segmentation faults more easily. Also, it will detect memory leaks to improve the quality of your code. So, essentially this week’s section is about catching bugs out there in the wild.