• Advanced search options...
Common Tasks
Recent Posts
Tags
Translate This Page
View This Blog In
Archives
Archives

VB Refactoring

MSDN Blogs > Somasegar's WebLog > VB Refactoring

VB Refactoring

19 Nov 2004 6:29 PM
  • Comments 32

A few weeks ago, I wrote about Edit and Continue support for C# in Visual Studio 2005, in response to overwhelming customer feedback.  Thanks for your wonderful words of support and great feedback.

 

We’ve also had tremendous feedback on the MSDN Product Feedback center among the VB community asking for Refactoring support.  (If you’re not already familiar with Refactoring, click here for a brief explanation.)  As many of you know from reading the VB Team Blog, the VB team is NOT going to be able to implement Refactoring in Visual Studio 2005.   This is disappointing to all of us and I wanted to talk a little bit about what went into that decision.

 

The VB team spent a great deal of time investigating how they could add Refactoring to VB 2005 and were very passionate about finding ways to get it done while still delivering on all the other feature commitments that we’ve made.  It was a long, drawn-out, hard discussion internally and has become an emotional issue on the blog after they posted the status.   When the team was trying to plan how to implement this feature, they were also faced with the reality of having a lot of work that needed to be done before we could deliver a great product to you all with quality on the already committed feature set, and refactoring is a large and complex feature.

 

Was the VB team listening to their customers?  Absolutely.  In the end, I discussed the feature and what it would take to implement with the team and decided that we could not fit it into our plans for VS 2005 without significantly delaying the entire Visual Studio 2005 product release.  This was a hard decision and trade-off that we had to make.  Deciding not to implement a feature that has community support and passionate advocates internally is one of the hardest decisions involved with shipping great software.  Refactoring in VB is on the list of features that we will consider after we get done with Visual Studio 2005.   

 

VB.NET in Visual Studio 2005 is our best VB ever.  With the return of Edit and Continue, more than 500 Intellisense code snippets, My, AutoCorrect and literally dozens of other VB features, I am confident that developers are going to love it.  We’re making the hard decisions that we need to make in order to get a great Visual Studio 2005 product to you as soon as we can.

 

Namaste!

Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post
Comments
  • richy_roo
    20 Nov 2004 12:35 AM
    This is really, really sad.

    The refactoring features increases productivity and VB.NET is meant to be a 'productive tool'. I really think there's been a mistake here.

    Code Snippets! useful for the 'hobbyiest' a term which occurs frequently, but isnt that kinda anti-refactoring - taking prebuilt code, which should really be method calls and copy/pasting them x times through your application.. 'anti-refactoring'.

    I just think that Code snippets in, Refactoring out, adds weight to the hobbiest tag. That makes me sad.

    After the hype there still the message spreading that c# is the 'main language' and now the news that c++ is the future and should be considered in 2005. lets fly the VB flag and get the OO stuff in there..

    C'mon the c# team got edit and contine...

    please, please, please give us refactoring, squeeze it in somehow...

  • Daniel Moth
    20 Nov 2004 3:05 AM
    For some of us, the syntax of the language is irrelevant when making a choice and we make it based on features. I like to call us professional .NET developers (no language labels).

    >>VB.NET in Visual Studio 2005 is our best VB ever.
    What is it exactly that VB gets with Whidbey? Snippets and My (just code examples, no real value) and a lot of catching up to C#2003 (this was necessary). That's it! My blog has a lot more on the subject but basically the gap (feature-wise) between the two languages widens. Throw into the argument perf and VB is a lost cause for non-hobbyists devs that don't care about the syntax.

    Now, to be honest, I understand what you are doing from a business perspective: Driving the professional community to C#; just come out and state it please so we can all stop talking and arguing about it.

    Right now there is only one killer feature when programming in VB: Background compiler (something it always had).
  • James Snape
    20 Nov 2004 3:14 AM
    I guess the VB developers are understandably going to be a little pi**ed off with the lack of feature. But as you know from past posts, I agree that you have to cut features to make a schedule. It's always tough, but hey - there's always the next release.

    James.
  • Stefano Demiliani
    20 Nov 2004 4:52 AM
    I can understand that implementing Refactory on VB could be a long work, but I'm terrible disappointed for this lack on the next VB version. Why VB must be always a step under C#?
    However, I've a personal question: why spent so long time to implement a feature like MY? I think I'll use it not too much often and personally I don't think it could be really useful and revolutionary. All the thing you could do with MY you can easily do NOW. Who has schedule the working table for the VB staff?
    We don't need toys like MY, we need working tool like Refactoring. :(
  • Frans Bouma
    20 Nov 2004 6:27 AM
    +1 for Daniel Moth's argument. Just come out and confirm what a lot of professionals already know.

    I also find it hard to believe that refactoring was too much to do. After all, the VB.NET compiler does compiling behind the scenes, it knows EVERY symbol and where it is located. The core issue for all refactoring tools is: where to get the symbol information so refactoring can be done reliable? In VB.NET, the compiler knows this, the code is already analyzed, the results are there, ready to be used.

    I understand the positioning problem Microsoft has and that there are a lot of professional developers using VB.NET, but make up your mind! OR make both languages evenly powerful and let hte user decide on syntax, or make the difference in positioning. What you're doing now is making VB act like a Visual Bob kind of toolkit which looks like it's targeted at beginners and hobbyists, alienating professionals.
  • Aaron Junod
    20 Nov 2004 6:46 AM
    This still hurts when I see threads about it. Personally, I'd rather refactoring then e&c or my, but I guess I'm just 1 professional vb.net developer in a sea of millions. Obviously by the tone of these posts, I'm not the only one though.

    You guys also hit the nail on the head when you state these features are targeted towards hobbyists. I spend much more time refactoring or writing new code then debugging (read unit tests), so to me, refactoring would have been the biggest productivity booster. Oh and I doubt I will touch the my namespace, at least without some in depth analysis of the IL it produces and what its writing for me.

    Now we professional vb.net people will need to bug mgmt to buy us a refactoring product if we want the productivity gains. Not good. I guess I will be stuck wishing we were a c# shop.
  • Alex Kazovic
    20 Nov 2004 7:04 AM
    I think it is a bigger issue than just refactoring in VB. Whilst I am disappointed it didn’t make it into VS2005, I could live with the decision if I felt that it would be included soon afterwards. Unfortunately, the time between releases seems to be measured in years rather than months. Therefore, for me, the issue is more to do with the development process/cycle. I would like to see releases (or add-ins) for VS more often than the current schedule.
  • Stefano Demiliani WeBlog
    20 Nov 2004 8:07 AM
    Again about VB.NET Refactoring
  • Mike Gunderloy
    20 Nov 2004 8:53 AM
    Well, I understand that it's too late to munge the schedule to get this in NOW. I do wish there had been more transparency and discussion of tradeoffs months and months ago, when professional VB .NET developers first got upset about the lack of refactoring. It seems clear that many of the most vocal VB proponents would have voted to dump the My namespace in favor of refactoring, had they been given the choice - though I suspect surveys of the entire VB marketplace might go the other way.
  • Mike Gunderloy
    20 Nov 2004 8:56 AM
    Well, I understand that it's too late to munge the schedule to get this in NOW. I do wish there had been more transparency and discussion of tradeoffs months and months ago, when professional VB .NET developers first got upset about the lack of refactoring. It seems clear that many of the most vocal VB proponents would have voted to dump the My namespace in favor of refactoring, had they been given the choice - though I suspect surveys of the entire VB marketplace might go the other way.
  • Darrell Scott
    20 Nov 2004 10:37 AM
    Well, this is the first I'd heard of this announcement, and it quite frankly breaks my heart.

    Refactoring was a key feature I was looking forward to seeing in Whidbey - something that could really improve our productivity and help keep the codebase maintainable. It's becoming patently obvious that Microsoft's priorities are with C# instead of VB.Net.

    As a previous poster mentioned, we don't really care for the syntatical sugar, particularly at the cost of a useful feature such as this.

    I'm beyond disappointed with this decision. We migrated to VB.Net with MS's promise that it would be fully embraced. That is clearly not happening.
  • Andy
    22 Nov 2004 3:09 AM
    You must question the sanity of introducing the "My" class and "code snippet" changes as opposed to refactoring. This just reinforces the point that VB will be the hobby language instead of the professional language it should be. A crying shame.

    The VB team needs to be keeping up with the C# team and doing more in order to correct the detrimental feeling about VB in the industry, but sadly, it appears professional features are excluded for changes that bring next to nothing to the party. IMHO it appears a decision was made to tailor VB as a classroom/learner language, and this underlying trend is what is worrying, not just that refactoring was excluded.
  • Ray
    22 Nov 2004 7:21 AM
    Personally, I don't care much about the refactoring in VB.Net. I don't even use in it C#. If you are a good coder, follow proper design guidelines and can envision your solutions properly prior to coding them, refactoring your code is a minimal and often unused process. I would much rather have a background compiler rather than a refactoring tool, and VB provides that. C# programmers complain that VB gets a background compiler and C# is behind VB.net in that respect. The background complier is the biggest reason I use VB over C# in many cases. You guys responding to this post act like people are using C# over VB.Net because of a refactoring tool. How about losing the background compiler and replacing with a refactoring tool? You'll still complain. Please. You guys are arguing for the sake of arguing. Look at both sides and you'll see that neither language IDE is better than the other, and both provide unique features that make them productive.
  • Radi
    22 Nov 2004 8:33 AM
    Ray, these guys are not arguing just for the sake of arguing but because they have a clear concept in mind of what is and is not important to have in VB.NET. I think throwing in the background compiler is kind of distracting from the main discussion here: why did My do it into VS.NET2005 and refactoring didn't?

    I understand the schedule problem, but I'm very disapointed about this. This was THE reason I was waiting for VS.NET2005. Now I'll switch to SharpDevelop as soon as their refactoring support has been built in.
  • Ray
    22 Nov 2004 10:25 AM
    Radi, you help clarify my point. If you only use a particular language and IDE because you need and possibly rely on a refactoring tool to produce good, efficient and maintainable code, all I can say is I'm glad I didn't hire you.

    From the refactoring link Somasegar supplied: "I'd bet you would agree that a significant part of any engineer's day is spent re-working existing code to become in some way 'better.' In many cases, 'better code' is a subjective term, but some common improvements include: adhering to OO-best practices, increasing type safety, improving performance, and increasing code readability and maintainability."

    In my opinion, if you are on my team and you are spending a significant part of your day rewriting and reworking code, you'll be finding a new job very quickly.
Page 1 of 3 (32 items) 123