Over a million developers have joined DZone.

Wish List for the Visual Studio Editor and Debugger: Drawing Inspiration from Other IDEs

DZone 's Guide to

Wish List for the Visual Studio Editor and Debugger: Drawing Inspiration from Other IDEs

· ·
Free Resource

One of the benefits of using more than one development platform, more than one IDE, and more than one debugger is that you gain a better understanding of what your personal ideal development workflow looks like. It might well be the case that no single tool provides every feature you're excited about, which is what I feel these days. Because Visual Studio is my long-time (since 1999) favorite IDE and debugger, here are some features from other tools I'd like to see integrated in Visual Studio.

Inspired by command-line debuggers, like WinDbg/GDB/DDD/DBX

Command-line debuggers tend to make automation much easier than their visual counterparts. Visual Studio 2010 used to offer VBA macros, which you could use for fairly sophisticated automation. For instance, you could have a breakpoint trigger a macro that would set another breakpoint, dump out all thread stacks, look for local variable values, and evaluate complex expressions. In Visual Studio 2012, macro support has been removed from the IDE, which makes command-line tools even more powerful in comparison.

Here are some of the things you can do in command-line debuggers that you can't do in Visual Studio today:

  • Set a breakpoint when a large memory location is read/written. 
    This is something you can do in WinDbg using the !vprotect extension command to configure a PAGE_GUARD page, and then process the exception Windows will raise when the memory is accessed.
  • Run an arbitrary debugger command when a breakpoint is hit. 
    In WinDbg, any breakpoint you set (including data breakpoints) can run any debugger command -- and decide whether to actually stop execution or continue as if the breakpoint wasn't hit.
  • Execute a set of debugger commands from a script file (the aptly named $$>< command in WinDbg).
  • Inspect managed heap contents, possibly running a command for each interesting heap object you encountered. 
    This is very useful for managed memory leak diagnostics. For example, you could run the !gcroot command for all objects of a specific type: 
    .foreach (obj {!dumpheap -type MyNamespace.MyClass -short}) {!gcroot obj; .echo -----;}
  • Load debugger extensions (like SOS or SOSEX) and extend your debugger with arbitrary commands. For example, SOSEX has a great variety of stack listing, object inspection, and synchronization-related commands that you could then use.

Inspired by Xcode

The Xcode IDE has a mixed reception from developers. I think most people moving to Xcode from Visual Studio will find it inadequate, but it actually has a few very nice features both in development-time and during debugging. This is not to say that I would actually want to do most of my development in Xcode -- but I've already been spoiled by Visual Studio :-)

One thing Xcode is really good at is static code analysis, which it performs on the fly. Now, Visual C++ also has static code analysis (the /analyze compiler switch), but it only runs when you compile your project, and takes quite a while to produce errors. Also, there's a big problem with signal to noise ratio, which I wish were addressed in future releases of the compiler. Here are a couple of examples:

  • Detecting a null pointer dereference and explaining where it's coming from. (This is actually something Visual C++ can do, but with less explanatory details.)


  • Detecting reference counting errors.


  • Detecting errors that result from calling methods on a nil pointer, that would return garbage in the case of structs.


Another thing the Xcode debugger is pretty good at (thanks to the underlying lldb debugger engine) is smart breakpoints, and performing a variety of actions when a breakpoint is hit. The Apple version of macros is AppleScript, and Xcode breakpoints can run an arbitrary AppleScript script as well as any lldb command.

For example, you could configure a breakpoint so that it takes a screenshot of your iPhone Simulator whenever it's hit, using the following AppleScript script [source]:

tell application "iPhone Simulator"
end tell

tell application "System Events"
       tell process "iOS Simulator"
               tell menu bar 1
                       tell menu bar item "iOS Simulator"
                               tell menu "iOS Simulator"
                                       click menu item "Hide Others"
                               end tell
                       end tell
               end tell
       end tell
end tell

do shell script "screencapture -m /tmp/screencapture.png"

Inspired by Eclipse

Although Eclipse draws lots of criticism -- it's slow, buggy, and some say ugly -- it has an unparalleled set of built-in refactorings and code-fixes that make most other IDEs pale in comparison.

First, just take a look at the Refactor menu in Eclipse:


Now, many of these things can be added to Visual Studio through ReSharper or CodeRush or similar tools, but it's actually very nice to have these features in the out-of-the-box IDE experience. Also, the code completion and error-fixing offered by Eclipse is so powerful that some people say you can create a new project in Eclipse, and just by using Ctrl+Space generate the entire source code for Eclipse itself ;-)

For example, here's Eclipse offering to fix a problem where an anonymous class method is trying to access a non-final local variable from the enclosing scope:



I often suffer every minute I have to spend outside of Visual Studio. The shortcut muscle memory, the powerful code editor, and of course my favorite language -- C# -- make it somewhat a pain to use anything else. That is why I am constantly looking for more features to extend that experience -- so that I can spend even more time in Visual Studio and be even more productive.

I am posting short links and updates on Twitter as well as on this blog. You can follow me: @goldshtn


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}