It would be great if there are more tutorials and people sharing their tricks.
I definitely agree with that.
The crucial part is that debugging is very much driven by how the code is written. This means, some code is extremely hard to debug while other code can be extremely easy to debug and, the difference is, how the code is structured/written.
In any complex program there should be a debugging "layer" activated by defines. That layer should consist of, among many other things, a copious number of asserts throughout the code ensuring that the programmer's assumptions are valid (invalid assumptions are a very common cause of bugs.)
Another things that makes debugging difficult is the use of the heap to store everything. That makes it difficult to see bad data by just eyeballing it. When distinct blocks of memory are allocated for different purposes, not only it makes debugging a lot easier but, it also usually makes the program faster.
Another bad habit that makes debugging difficult is not resetting pointers to nil after freeing the block it pointed to. That's the reason why FreeAndNil should always be used because that way, if the class/pointer is reused then there will be an access violation instead of memory corruption which may only become evident tens of thousands of instructions later which makes it extremely difficult to figure out what happened.
One useful "trick" is data breakpoints. Those are often extremely useful when a variable is eventually set to a bad value. I think FpDebug supports them but, I haven't needed them in quite some time so I can't be certain.
IMO, a good debugger is as important as a good compiler. The reason is simple: because everyone makes mistakes and a good tool to find them saves a lot time and aggravation but, the programmer has to help the debugger help him/her.
Recent
