Update: I just realized I’d forgotten one of my favorite shortcuts: Alt + N. So what does it do? See the list below! Suffice it to say, after using it I no longer worry about getting lost in tangent code while debugging. 😉

---

I love a good shortcut. I love it when I can perform a task without removing my hands from their regular location on the keyboard, and without having to look down to find that one special hard-to-reach key. Now as every moderately experienced programmer knows, debugging is often an essential part of the job. In fact it can sometimes take up the clear majority of your time for extended periods. That’s why I’ve always found it so strange that the shortcuts for regular debugging actions such as step over, step into, step out of and so on have such (in my opinion at least) impractical shortcuts.

The following is a scheme of key bindings that I have been using for two or three months now, and which I find natural and easy. The effect of this change has been bigger than I had anticipated: Since I no longer need to pause to look down at the keyboard while stretching for the F11 key for example, my train of thought is slightly less prone to being interrupted. Cutting out these minimal context switches means I can focus better on the code, which means I work faster and spend less mental energy keeping track of where I am, and what is going on — and there’s your improved debugging workflow.

(*) shift + F11 is a common shortcut for “step into”.

Shortcuts

These are the main shortcuts I’ve added. Some are inspired by the use of Vim (J moves the cursor to the next line in Vim – her it steps to the next line of code), while others are based on mnemonics (G for “Go” to either start or continue debugging, S for “Stop“), etc.

Here`s the full list:

Alt + G: Debug.Start
Start debugging (“run”). If stopped at a line with a breakpoint, this will execute it and continue.

Alt + S: Debug.StopDebugging
Stop debugging.

Alt + J: Debug.StepOver
Execute the current line (but wait at the next one)

Alt + K: Debug.StepInto
If the current line is a method call, step into that method. Memorizing it: This is the “alternative” to J: In Vim, K moves the cursor up to the previous line (whereas j moves to the next line). In this context, the alternative to “step over” is to “step into”.

Alt + Shift + K: Debug.StepOut
Run until the end of the current method, and step out of it, then wait at the next line in the calling method (This is sort of an inverse of the previous command, so we just add Shift).

Alt + H: Debug.ToggleBreakpoint
Add or remove a breakpoint on the current line (mnemonic: Think of a breakpoint as something you “Hit“).

Alt + Shift + H: Debug.EnableBreakpoint
Disable (or re-enable) a breakpoint on the current line (meaning execution won’t stop there, but you can keep the breakpoint for use later). This just adds the Shift key because it’s kind of a variation on the previous binding.

Alt + C: Debug.CallStack
Open and change focus to the Call Stack window, where you can see a hierarchy of method calls related to the current method.

Alt + I: Debug.Immediate
Open and change focus to the Immediate Window, where you can enter code to fiddle with data currently in context (for instance filtering data in a list, or changing the value of a variable, etc).

Alt + N: Debug.ShowNextStatement
Move focus back to the current debug location: If execution has stopped at a breakpoint, and you navigate away from it to investigate. This will take you directly back to the active breakpoint.

Conclusion

There are a bunch more debugging-related operations you could add special key-bindings to if you like, but these have been sufficient for me at least. I use most of these quite frequently, and as you’ll see if you try this, they are all easily reached, and hopefully surprisingly easy to learn.

Give it a chance for a day or two, and I’m pretty sure you’ll be glad you did, and not want to go back.