Visual Studio: A Wishlist

As you may know, a couple of months ago, one of my friends and teammates posted a couple of blog entries (here and here) about the Visual Studio Fakes toolkit. These posts started a brief dialog with Peter Provost, a Microsoft Visual Studio Program Manager Lead. Though the dialog wasn't fruitful, it did start me thinking. If I consider the time spent developing the Fakes library at the very least wasted and most likely harmful to our industry, what would I have the Visual Studio development team working on? What follows is a wishlist of features I want to see in my day to day code editor.

Less is More

Visual Studio is used by developers working on a wide variety of teams who build a lot of different types of applications. Because of this, it supports many features that are used by a subset of those teams. For example, the TFS team features are integrated into the IDE, though only a portion of .NET dev teams actually use them so are the server explorer and WinForms/HTML/XAML/CSS/XML editors. There is even a built in web browser!
I would love to see Visual Studio stripped down to a very basic state and all the additional tools converted to plugins that are easily added by teams who need or want them. I see the core purpose of Visual Studio to be managing the fairly complex Solution and Project files, providing syntax highlighting and intellisense, and debugging. Most other features should be optional via plugins. In addition, it would be nice if the Solution and Project files included some kind of manifest of the plugins used, so that when I load a web project, I don't get a WinForms editor and when I load a Silverlight projects, I don't get a T-SQL designer. When I load a console project, I don't want a web server. And regardless of which type of project I load, I don't want MS Test or a hacked—up version of IE6 loaded!

Play Nicely with Others

A lot of the requirements for compatibility with other tools would be solved by not having so many built in features, but I think it is still worth calling out as a separate point. I have been using git source control for a while on all my personal projects and we started using it exclusively at work a couple of months ago as well. When using git or any other tool that directly modifies the code files outside of the editor, Visual Studio often gets into a confused state where it accidentally overwrites the files I just checked out. This has lead most members of my team to close VS when reverting or switching branches, both of which are common when using a source control system like git. While I have focused on git, this applies to any tools that edit files outside of the IDE.

Personalized Code Styling

How many hours of development time have been spent arguing about the placement of braces and line breaks? Wouldn't it be nice if there were a way to let Joe put his curly braces on the same line as the method declaration while Jim puts his curly braces on the next line? I have often seen the maintainers of open source projects complain about the "I reformatted your code with ReSharper" pull requests. I would love to see Visual Studio save code in a simple, canonical format and yet display it in using my custom styles. Of course, this should be done through a plugin rather than as a core feature because a lot of teams wouldn't need the feature or may edit code regularly outside of VS.

In Summary

Visual Studio is a great tool for .NET development. I use it every day and like it more than any other IDE I have tried. There are probably a lot of other features that would be nice to have, but I think that if the overall size of Visual Studio were reduced by extracting plugins and, making the creation/distribution/sale of new plugins much easier, we would all benefit.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc
Read more