I find that the problem is that the better you become at engineering (i.e. designing and writing your code) the worse you become at debugging. This is because in a well designed system you have many (as many as possible) independent components that you can look at one piece at a time and you've written the appropriate unit tests for them. And subsequently you don't spend that much time in the debugger. In my experience this way most bugs (integration bugs aside) are rather trivial. In my own projects (over the past +15 years) most of my debugging involves just running gdb on my unit test until a test assertion fails, setting a breakpoint before the failed assertion and rerunning so that I can step through the computation.
On another note there's actually this thing I'd like to call "debuggability".
I find that if you just thinking of this as a measure of how easy your program is to debug and when making design decisions you think of "which design makes this thing easier to debug" your program will be simplified. To me mean high "debuggability" at design level means cohesive independent components which makes it easy to write unit tests for them which then subsequently makes it easy to debug them as well.
Other thing is sometimes I see people write code like this:
getFoo()->getBar()->doComputation();
or something like
doComputation(getFoo()->GetSausage());
And depending on your debugger this can be super inconvenient to debug through. For example with gdb trying to step into any specific function basically requires you to find that function and set a breakpoint there. Otherwise you'll have to go through a lot of unrelevant stuff (especially if you're for example using std::unique_ptr)
If you used some temporary variables to store the results of those function calls again you'll make your program more "debuggable".
Any decent high-level debugger will provide some way to distinguish between your code and stdlib code when stepping, such that you don't end up inside std::unique_ptr and similar.
Good ones will let you set a breakpoint on a subexpression, so in this case you'd just highlight the call that you want, and it'll stop right before it happens.
On another note there's actually this thing I'd like to call "debuggability".
I find that if you just thinking of this as a measure of how easy your program is to debug and when making design decisions you think of "which design makes this thing easier to debug" your program will be simplified. To me mean high "debuggability" at design level means cohesive independent components which makes it easy to write unit tests for them which then subsequently makes it easy to debug them as well.
Other thing is sometimes I see people write code like this:
or something like And depending on your debugger this can be super inconvenient to debug through. For example with gdb trying to step into any specific function basically requires you to find that function and set a breakpoint there. Otherwise you'll have to go through a lot of unrelevant stuff (especially if you're for example using std::unique_ptr)If you used some temporary variables to store the results of those function calls again you'll make your program more "debuggable".