My wish-list for the next Visual Studio.NET release

I'm now working for a week or so with VS.NET 2003 and it has some neat features that version 2002 didn't have which are, well, neat to have, but also started me thinking why they are implemented the way they are and why there is so much ground left untouched. Below I've formulated some wishes for the next version of Visual Studio.NET (2004?), and as with every wish-list, I hope the wishes come true, or better: what's wished for is a bad example of a short sighted vision of how reality should be and the next version of VS.NET (2004?) will prove that :)

Compilation (C#)

  • Full error harvesting during compile pass. I work with C#, and what I learned during my study CS was that a compiler should recover from an error and should continue with finding errors as best as it can. The current C# compiler fails in this area. F.e. if you make a typo in the name of a local variable and you do that twice or more in the same local scope, the compiler will only find the first error. This is also true for type mismatches, thus using the same variable twice in a wrong way will enlist 1 error, so you fix it (it's monday morning, your head isn't that clear and focussed) and recompile and see a similar error but 2 lines below it (or in the same line). If the compiler finds all errors at once, you can fix them in one go and do not have to recompile a lot. (on the fly error-checking would be even better, but that is performance intensive)
  • If one assembly is build and it fails, do not compile related assemblies as well. When you have a solution with more than 1 project, and you want to rebuild a given project that is referenced in another project (using the 'rebuild' option in Visual Studio) and the rebuild fails, you'll also see errors in the project(s) referencing the project you just build. This can be very annoying, and is unnecessary since you didn't want to rebuild the other projects. It's also weird because if the build succeeds, you will not see any errors found in referencing projects, as if the re-compile of those other projects is not done when a rebuild of a single project succeeds.

Editor (C# / general)

  • Persistent bookmarks. Now the bookmarks you set in a file are gone the moment you close the file in the editor, which makes the concept of bookmarks not that useful.
  • Persistent outline folding. Now all regions (outlining) are collapsed or expanded when a file with outlining is loaded (depending on the settings) and the folding is not persisted when you close the file. This can be annoying when you have a private members region and a properties region. Both are collapsed when loaded but you sometimes want to keep open the private member variable region when you are working on a class.
  • Interface stubbing should be more enhanced. The feature to stub out a complete interface is a time-saver at first but when you use it for a while it isn't much useful when you use it for your own interfaces. The reason for this is that you have to copy over your xml comments from the interface definition to the stubbed out versions, which can be time consuming. It's then faster to just copy the complete definition of the interface and add public/protected statements and a simple body. The stubber should copy, when possible, the xml comments from the interface definition, so the stubbed out code is more useful. Also, it is now placed in its own region. What if you do not want that? It would be nice to have a certain amount of configuration settings for these kind of features, like the interface stubber.
  • Give 'smart indenting' a better brain. Although smart-indenting is a little smarter than 'block indenting', it has some weird issues. For example, if you hit enter twice when you are at the end of a line, you are 2 lines below the line you typed, indented. Now hit cursor-up. The cursor is all the way to the left, at the start of the line. If you want to add something there, you either have to hit enter again, start typing, erase the line above it, or hit tab a few times. This is odd because when you hit enter for the first time during that twice-hit session, the cursor was on that line, indented, so where are these tabs all of a sudden? Another nasty habit of this indenter is the fact that it gets confused with switch statements rather fast and adds a tab too many. A last thing that would be very handy (and VB.NET users have this for a long time) is the automatically insertion of start/stop braces when you complete an if expression or for expression or other statement that is the start of a block, a local scope.
  • Automatically stubbing of the base class' abstract methods/properties. The override stubber is nice, but as you have to implement abstract methods of the base class you inherit from, it would be nice to have a stubber like the interface stubber, and then with xml comment insertion as well :)
  • Better organization of winforms generated code. When you are designing your GUI in the form designer, it will generate code for you in the code file of the form class. This code is randomly placed in your own code it seems. It creates one region where the form initializing code is stored, however the form's dispose method is not placed in that region, and most of the time you definitely do not need that routine. It would be nice if that routine was placed in the generated region as well. Also, the definitions of the controls are placed where your own private member variables are declared as well. Even if you create 2 regions for that the form designer will sometimes place new controls in the wrong region. It would be nice if you can define a region where the generated code is placed so you'll see the code you have typed yourself and are not confronted with the generated code.
  • Property getter/setter generator. Everyone who has worked with the VB6 class generator knows that it had a great property add feature which generated both member variables and get/set properties for these members. VS.NET still lacks this feature, or better: it lacks a feature that lets you add properties fast. I now use QuickCode, it helps, but it is still slower than the VB6 property generator.
  • More fine-grained settings for editor customization. If you check out the option dialogs in Visual Studio.NET you'll see different options for the different language editors. Now, I can imagine the average C++ developer is focussed on other things than the average VB.NET developer, but why are some features available in some language editors while they are non-existent in other language editors? F.e. the C++ editor lacks some options that are present in the C# editor. If you, as a C++ developer, and you would have these settings and you do not want them, you can switch them off, but if you do want them, you can switch them on. Now you can't. It also bugs me why the editors do not have more settings for tweaking the editor more so it behaves like you want. It's a tool a developer uses for a long period of time during a day, so having more options to make the editor work they way the developer wants is only an advantage. An individual developer is not helped with an "surveys showed us that this is what most developers wanted"-explanation.
  • Build a new ASP.NET editor. I don't know if Matrix will turn out to be the next ASP.NET editor, but the current one in Visual Studio.NET has some serious issues, while competing products like Dreamweaver do not have them. A new, better anticipating editor is necessary, an editor who knows what kind of content is edited.

IDE in general

  • Refactoring tools. Every self-proclaimed good Java IDE has them: refactoring tools. VS.NET has just one, a search/replace tool (although it is rather good). At first I wasn't that in favor for refactoring tools because they imply an ad-hoc coding style. But since I use an ad-hoc coding style while writing my O/R framework (because remodelling of code is necessary a lot during OO development, you'll never get it right the first time), I miss refactoring tools a lot. Even a small set of tools would be a good start. Buying a 3rd party plug-in is an option but you don't pay top dollar for an IDE that requires you to invest even more money to make it complete.
  • Multi-row tabs. I sometimes have a lot of tabs open in the IDE, 15 or more. Flipping through them is a pain, why didn't MS include a multi-row tab control for those tabs?
  • A faster debugger. I work on a P3-933 with 384MB of Ram and XP. I know the machine is a little dated, but when your solution gets bigger and bigger and you want to debug an assembly and want to step through some code while having open a tree of local variables, it gets really really slow, even in VS.NET 2003. I sometimes see member variables change in the Locals view 2 seconds after the step over was completed. VS.NET 2003 is a little faster, but it also makes mistakes in enum int to enum text conversions sometimes, i.e. the snapshot of the state of an object shown in the debugger's Locals window is not reflecting the real state of the object. Perhaps this is a result of the performance enhancements, but it makes debugging more time consuming this way.
  • Make editor tabs slideable to the side like f.e. the solution explorer. You can't semi-hide an editor tab to a small tabstrip at the side of the tab area for later usage, you have to close the tab and open it later.
  • The help tab should be special. In VS.NET 2003, the help isn't displayed on the start page tab, but on another tab. When you flip through the editor tabs with cntrl-tab, you also come across the help tab. This shouldn't be the case. When editing code, the help tab is for assistance, it isn't part of the editing process.
  • Make source control truly integrated. At the moment when renaming a file when this file is under sourcecontrol controlled by Sourcesafe, the rename is not reflected in Sourcesafe itself. Instead, a new file is added, which will cause cluttering in Sourcesafe itself plus you'll loose history information on the file because that information is still stored with the file with the old name. It should be possible to select an option to make these changes also be propagated to Sourcesafe, if you want. There are other caveats with Sourcesafe, the one I encounter the most is this lack of true integration. Overall I think a sourcecontrol system which is more focussed on heavy multi-user development is a must.

*Pfew* :) Of course there are more features to wish for and there are perhaps features I wish for which are not beneficial to others. If you have more features you want to see in the next Visual Studio.NET, enlist them in a blog so MS gets notified and perhaps the next version of VS.NET will include all this with all the stuff we already know it will contain, like generics :)

8 Comments

  • I think it removes the tabs if you choose to <enter> another line down because a lot of people (me included) dislike lots of whitespace on otherwise empty lines. If you want it to redo them when you move upward that could cause some really funky stuff when you're just cruising the sourcefile looking for something to copy and you see the cursor jumping around to each line's "next logical place to insert stuff" :)





    I agree with the rest though, especially the compilation issues.

  • Yeah, the whitespace is indeed a burden. However, the editor knows it should indent when hitting enter, the editor could simply look at the indentation of the line ABOVE the current line (if the current is empty). Ah well... :)

  • Your list is great! I'd like to add one minor thing:





    Give us an option to either: remove the "Add Task" line from the task list or possibly move the "Add Task" line to the bottom of the task list.





    Visual Studio takes up so much screen real estate - the add task line takes up so much room for something that I never use.


  • Re Error harvesting. Long ago I worked on with a PL/1 compiler that attempted to continue after errors. It had to assume what you meant to say instead of the error, and one wrong assumption generated a mass of meaningless errors.





    Be careful what you wish for!

  • David: heh yeah, I remember those days with the Sun 'CC' compiler when you forgot a ';' all hell broke loose. Fixing that ';' and all errors went away. :) However, what I ment was clearly repetitive errors which can be found but are now skipped. But indeed, we should be careful what to wish for :)

  • About the help tab: I find it much easier to use external help. Then I can use Ctrl+Tab to switch between editors and Alt+Tab to switch to the help window and back.

  • Editor tabs in VS are displayed like tabs and behave like MDI Child windows. When you press control+tab, the focus goes to next in the "Z-Order" not to the next tab page!. This is confusing and is moving away from the normal working of Tab Sheets!

  • Refactoring:



    I agree with all the comments on the need for a REFACTORING tool. If the programmer renames a method, class or variable/properties anywhere in the code these changes need to be made automatically throughout the project.





Comments have been disabled for this content.