I alluded to some debugger cardinal rules in a prior post. However, they may well be something that debugger writers know, but haven’t written down. To remedy, I’ll start the list here.
My first two rules:
1) Never lie to the user. Telling them incorrect information is an unpardonable sin, punishable by having to debug the user’s programs for them.
2) Don’t change the behavior of the target app. This may not be always technically feasible, but minimize the effect as much as humanly possible. It drives me nuts when something operates differently under the debugger when the debugger didn’t have to muck with the process. Tool like profilers and automatic error detection (e.g., BoundsChecker) should abide by this rule as well.
Russ Osterlund adds two more:
3) Never appear “weaker” than the target app. (Classic examples of this are the VB debugger and the VS.NET managed debugger that prevent one from stepping into system code or disallow one from viewing valid “memory” addresses.)
4) Never make the user work harder than they need to — debugging is tough enough without the main instrument of the effort getting in the way.
Russ’s PEBrowse Interactive does a great job of adhering to #4. Context is everything. Russ’s program has killer context menus that make it trivial to do just what you need to do. My dream debugger would be Visual Studio with Russ’s context commands.
Anybody else got any inviolable debugger rules to add?