In Writing Solid Code[0], Steve Maguire recommends stepping through every line of code, in a symbolic debugger.
Sounds crazy, but I usually end up doing that, anyway, as I work.
Another tip that has helped me, is to add code documentation to inline code, after it’s written (I generally add some, but not much inline, as I write it. Most of my initial documentation is headerdoc). The process of reading the code, helps cement its functionality into my head, and I also find bugs, just like he mentions.
> In Writing Solid Code[0], Steve Maguire recommends stepping through every line of code, in a symbolic debugger.
> Sounds crazy, but I usually end up doing that, anyway, as I work.
This doesn't sound crazy to me. On the contrary, it sounds crazy not to do it.
How many bugs do we come across where we ask rhetorically, "Did this ever work?" It becomes obvious that the programmer never ran the code, otherwise the bug would have exhibited immediately.
When I think about stepping through the code in a debugger, I think about how hard it is to even run all the code, for the projects I've had the most trouble on.
1. One was soft real-time and stepping through the code in a debugger would first mean having a robust way to play back data input on a simulate time tick. Doing it on live sensor data would mean the code saw nonsense.
2. One requires a background service to run as root. Attaching a debugger to that is surely possible but not any fun.
3. Attaching a debugger to an Android app is certainly possible, but I have never practiced it, and I'm not sure if it can be done "in the field" - Suppose I have a bug that only replicates under certain conditions that are hard to simulate.
You're not wrong. But maybe bugs build up when programmers don't want to admit that we aren't really able to run our code, and managers don't want to give us time to actually run it.
I also do this quite a lot but pair it with an automated test to repeatedly trigger the breakpoint with different values and round out the tests and code accordingly.
Sounds crazy, but I usually end up doing that, anyway, as I work.
Another tip that has helped me, is to add code documentation to inline code, after it’s written (I generally add some, but not much inline, as I write it. Most of my initial documentation is headerdoc). The process of reading the code, helps cement its functionality into my head, and I also find bugs, just like he mentions.
[0] https://writingsolidcode.com/