Welcome to AddressOf.com Sign in | Join | Help

The whole Refactoring/VB.NET debate

Refactoring?  What's that? Wow, what do you know, you can find out the answer by going to the Refactoring Home Page; however, to summarize:

Refactoring is a technique to restructure code in a disciplined way. For a long time it was a piece of programmer lore, done with varying degrees of discipline by experienced developers, but not passed on in a coherent way. In July 1999 Addison-Wesley published my book describing Refactoring. The book describes the refactoring process, together with a catalog of refactorings. Since that book refactoring has played an increasingly visible role in software development. There is more written about it and since the beginning of 2001 we've seen a lot of development of a new breed of refactoring tools, which I believe will make a huge impact to the work of software development.

Paul Vick was kind enough to points out that VB.NET will have some refactoring support in the next release.  How much or how little will be determined by several factors (time to market and user feedback are a couple of examples).  He even lists out several areas that refactoring tools are able to accomplish and asks the community to leave feedback as to what features do developers consider a priority for getting into the next release (along with the reasoning why a developer considers this feature a necessity - ie. “C# does it“ isn't enough of a reason).  His post has generated a large amount of responses.

Another thing he points out is that it might not be called 'Refactoring'.  Some reasoning behind this is that VB.NET developers may not know what refactoring is and may just skip over the menu item.  Personally, I don't care what it is called.  I'd like to see it (whatever it's name is) there purely from the standpoint that anything that can save me some time and brain power... I'm all for it.  Now, bear in mind, 'Refactoring' has been around for a very long time.  It's only until recently (2001'ish) that there was a term for it.  Technically, 'Find and Replace' is a rudimentary form of refactoring.

Now, here's where I do draw the line.  Just because it might be called something else in VB.NET... does not mean that VB.NET is being “dumbed down“ as several people have expressed concern over.  What I find most interesting is that 'Refactoring' is something that occurs more often because you didn't do a well thought out design in the first place... something that most VB.NET developers are accused of very often.  Now wait a minute, I thought that all C/Java developers designed their applications prior to actually developing them... therefore, what is the critical need for refactoring?  If it's so perfect the first time; what's there to refactor? ;-)  OK, I know I'm being a bit cynical here, but the point is that refactoring tools are designed to allow the developer to make project wide changes to the code (basically, 'find and replace' with some intelligence). 

I agree with G. Andrew Duthie when he states that it doesn't really matter what language you are using, we are all .NET developers.  However, I somewhat disagree with him concerning the languages need to be consistent with each other.  If they were, what would be the point of having different languages.  Each language is designed to offer various benefits that the others do not offer.  This is true whether your talking about VB.NET, C#, C++, J#, Cobol, Fortran, whatever.  As long as the language allows me to take full advantage of the underlying framework (including interop functions); I'm fine with however each language decides to implement this access.  This is where I believe the consistency should be and I think that Microsoft has the same view.

Whatever it's called in the end and to whatever degree the tools are implemented, whatever improves my speed to delivering product... I'm all for.

Published Monday, November 03, 2003 5:23 AM by CorySmith
Filed under: ,


# re: The whole Refactoring/VB.NET debate

Monday, November 03, 2003 12:26 PM by Douglas Reilly
I think that an internal language syntax that is consistent and coherent is a reason to call something by a different name in one language than another in many cases. However, in the IDE, when a new feature is added, and that feature is implementing a well known process (like Refactoring) calling it something different (especially if the stated reason is so as not to confuse the developers) is just silly.

# re: The whole Refactoring/VB.NET debate

Monday, November 03, 2003 12:45 PM by Cory Smith
I completely agree. As I point out in a later post, I think the feature(s) should be implemented in a manner that makes sense... not as some sort of menu item, but rather as a context oriented feature. As someone who has been using VB since day one, I personally don't see a problem with using the word 'refactor'. However, if it's called something else, I don't really care either. If it is called something else, I won't personallally feel 'dumbed down'. ;-)

Another point to keep in mind. If not all of the features of what some consider 'refactoring' are implemented and it's called 'refactor' in VB.NET... then the other side of the arguments will ensue. VB.NET states that it supports 'refactoring', but doesn't do blah, blah, or blah. An blah isn't done according to blah. Yada, yada, yada. So should it be called 'refactor' if it doens't do everything according to the 'refactoring' world?

Also, since most of 'refactoring' nothing more than a really cool version of search and replace, should search and replace be moved into the 'refactor' menu (if there is one)? My point here is what other features in the IDE should be moved to a 'refactor' menu if there were to be one?

# re: The whole Refactoring/VB.NET debate

Monday, November 03, 2003 7:57 PM by G. Andrew Duthie
I think you misunderstand what I mean by consistency. I don't mean that every language should implement its features identically (or even very similarly), as that would rather defeat the purpose of having different languages. But I don't think that there should be substantial differences in the feature set of each language, whether it's high-level features like XML commenting, or low-level features like unsafe code.

I agree with what someone else pointed out in the comments to my blog post...as long as the dev teams are evaluated based on units shipped of a given language, it's inevitable that they'll be working hard to diferentiate themselves, sometimes to the detriment of the people using the tools.

# re: The whole Refactoring/VB.NET debate

Tuesday, November 04, 2003 12:15 AM by Diego Vega
How old is the term blog? What about the verb google? I think "refactor" is a really cool term, and many know what it means already. They ones that don't know will learn, and will be able to discuss with Java, Smalltalk and even with C# developers about it in cofee breaks. However, I am open to hear what the VB.NET team comes with.

I also think that having some consistence in the IDE among different languages is a good thing. That is one of the principle behind Visual Studio. What if the VB.NET team decided to rename the file menu to something else? Maybe they come up with something better than File, but there is some value in sticking to File.

Besides, even if VB is a different language and it doesn't need to be consistent with C# or Java, it is not such a different programing model. That is the reason the wish list for refactoring tools is the same.


# re: The whole Refactoring/VB.NET debate

Monday, January 19, 2004 3:02 PM by Eric Mutta
I personally dont care what they call it - as long as its there! I wont feel 'dumbed down' either if they chose (IMO) somewhat simpler self-explanatory terms:

*Improve code
*Restructure code
*Modify code

or similar terms. I think what Paul Vick was implying is that people are more likely to click on a menu item with names similar to above, because they immediately reflect what you can achieve without requiring you to look up anything.

And as those who like to fiddle with their IDE's would know, regardless of what MS choose to call it, you can *change* the text displayed in the menu to whatever you want :) (heck, you can even change the mnemonic, the shortcut key, the image next to the menu item, move the menu onto a toolbar, move the item onto another menu eg Edit and who knows what else!).

# re: The whole Refactoring/VB.NET debate

Monday, May 17, 2004 4:46 PM by stefan demetz

# .NET Refactoring - revisited

Saturday, May 22, 2004 3:45 AM by Stefan Demetz
.NET Refactoring - revisited

# Refactoring no VB.NET 2005

Thursday, April 21, 2005 2:06 PM by Programando .NET

# Refactoring?  What's that? Wow, what do you know, you can find out the answer by going to the Refactoring Home Page; however, to summarize:<br>I do not agree.For more info go to System.String[],I disagree

Tuesday, September 26, 2006 6:18 AM by Refactoring?  What's that? Wow, what do you k
Refactoring?  What's that? Wow, what do you know, you can find out the answer by going to the Refactoring Home Page; however, to summarize:
I do not agree.For more info go to System.String[]

# VS.NET and &amp;quot;purdy code&amp;quot; aka .NET refactoring

Friday, January 05, 2007 5:39 AM by Gridding .NET

What would you like to be included in Whidbey? IMRO, the features should be divided into "REFACTORING"...

# Dumbing down VB.Net

Wednesday, July 11, 2007 7:58 AM by Daryl Johnson
I've been a VB programmer since VB 3 and now am a staunch VB.Net coder who won't use anything else. Along the way, I went from VB6/Classic ASP to the Java world. I must admit my eyes were opened and I learned a lot about design, classes and refactoring. I became a better programmer. While I still believe the .Net platform is the best platform, VB.Net in particular, at least at that point in my life (2002-2003) the Java coders had far more sophisticated design and coding methodologies. I have since then incorporated most of those techniques into my VB.Net coding. VB coders (sometimes) are used to rad/just get it done techniques but we are no less intelligent than the next C#/Java coder. The longer Microsoft keeps hand holding and worrying about whether those poor illiterate programmers can comprehend something as sophisticated as refactoring, the more other programmers will consider VB a toy language. Call it refactoring. That's what it is. I believe we can handle it.

# Refactoring no VB.NET 2005

Sunday, June 28, 2009 10:25 PM by Programando .NET

Refactoring no Visual Studio só no C#... Refactoring support in VB.NET Refactoring: Not for VB 2005

Anonymous comments are disabled