.NET Zone is brought to you in partnership with:

Sasha Goldshtein is a Senior Consultant for Sela Group, an Israeli company specializing in training, consulting and outsourcing to local and international customers.Sasha's work is divided across these three primary disciplines. He consults for clients on architecture, development, debugging and performance issues; he actively develops code using the latest bits of technology from Microsoft; and he conducts training classes on a variety of topics, from Windows Internals to .NET Performance. You can read more about Sasha's work and his latest ventures at his blog: http://blogs.microsoft.co.il/blogs/sasha. Sasha writes from Herzliya, Israel. Sasha is a DZone MVB and is not an employee of DZone and has posted 204 posts at DZone. You can read more from them at their website. View Full User Profile

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

03.20.2013
| 2698 views |
  • submit to reddit

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"
       activate
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:

eclipse_refactor_menu 

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:

eclipse_quickfix_menu

Summary

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 Sasha Goldshtein, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)