…and never get between a programmer and his jargon. Whoo wee… From SecretGeek.com, here’s apparently what our view of the VB programmer’s supposed to be:
(To prevent further flooding of Leon’s site, I’m linking to Julia Lerman’s copy of the image, I hope she doesn’t mind.)
“Ask Don Box for help.” Hmmmm. I kind of like that one…
I got a question from “Russ” who asks whether there’s something that can be done to avoid the annoyance of having to remember to start with Not when you are testing if something is not Nothing:
If Not x Is Nothing Then Console.WriteLine(”Has a value.”)
This is something I forget to do all the time, breaking the flow of my thinking. We’ve had requests for this in the past, so for Whidbey we added an inverse operator to Is called (can you guess?) IsNot. So you can write:
If x IsNot Nothing Then Console.WriteLine(”Has a value.”)
Just one of those little things.
Esmond Hart asks:
I code a lot of VB.NET and the bug I make most often is forgetting to return the result of a function call. Daft but true. How I would welcome an option that flagged each End Function statement without a Return statement immediately preceding it. Option EvenStricter maybe.
Well, we’ll actually be doing better than this in Whidbey! One of the major features that we’re implementing in the compiler for Whidbey is “flow of control” analysis. This allows us to track at compile-time the ways in which a method can execute and then give the user warnings based on that analysis. For example, take the following code snippet: (I realize it’s a nonsense function, but my brain is working slowly this morning and I can’t think of anything better.)
Function Test(ByVal Value As Integer) As Integer
Dim c,d As Collection
If Value > 0 Then
c = New Collection()
End If
c.Add(Value)
If Value < 0 Then
Return Value
End If
End Function
In Whidbey the compiler will be able to walk through the function and figure out the ways in which it might be executed, determining the following things:
Once we’ve determined these things, we’ll give warnings on them. Pretty cool, huh? (Yes, I know, compilers for the C family of languages [and many, many others, I’m sure] have had this for forever, but it’s nice to join the party.)
Frans points out that in the current version of VB.NET you can’t re-implement an interface that your base class implements. Although reimplementing a base interface isn’t a common scenario, there are some times (such as the one that Frans outlines) where it is needed. Although I don’t know whether this is in the PDC build or not, I don’t think it’s much of a revelation to say that the Whidbey version of VB will allow interface reimplementation. Doesn’t help now, but…
Just a quick one… The PDC build of Whidbey has XML Documentation comments in VB that look something like:
'@ <summary>
'@ A method.
'@ </summary>
The “@” was used as a placeholder while we did some testing and discussion about what the marker for the comments should be. An obvious choice would be ”’ (three comment ticks in a row), but we had some concerns that the comment/uncomment block IDE feature might negatively interact with it (i.e. you do “comment block” multiple times on a section of code and all of a sudden you’re getting weird XML Documentation warnings).
However, we’ve decided that we do like ”’ the best, so we’re going to slightly modify comment/uncomment block to add a space after the comment tick to ensure it won’t create XML Documentation by accident. So in the beta, XML Documentation comments will look like:
''' <summary>
''' A method.
''' </summary>
More feedback is always accepted. (Though, please, no accusations that we’re changing the syntax because we think VB developers are too dumb to understand “@”… <G>)
Now I know how dentists must feel when they’re drilling into the patient’s tooth and they hit a nerve. I think that previous to this I’d gotten at most, what, five or six comments? The refactoring item has 31 comments and counting. Whew.
First, let me say the comments about what refactoring tools are most useful are wonderful and will be passed along. They’re all great suggestions, and the team will be looking carefully at them as we think about what we’re doing in Whidbey. I can’t promise we’ll make everyone happy, but we’ll certainly try (as usual)!
Now on to the question of the name “refactoring”…
I think we should get one thing clear upfront: this has nothing to do with the perceived intelligence or sophistication (or lack thereof) of the average Visual Basic user. Every time I’ve ever had a chance to interact with living, breathing VB developers, I’ve come out of the encounter impressed as to how smart VB developers from all walks of life are. I’m sure we have our fair share of knuckle-draggers in the crowd, but, to be honest, this is the case for all computer languages – programming in C++ does not automatically make you intelligent any more than attending Yale University automatically makes you intelligent (both of these I can attest to first-hand). In my memory, there has never been a situation where anyone from the product team has ever talked about or discussed our customers with anything less than absolute respect. So although there certainly are quarters of this industry that do not treat VB developers with the regard that is due them, I can assure everyone here that they do not work for the Visual Basic team.
To put it even more bluntly: there is no question here of us thinking anyone is too “dumb” to understand anything.
Much of this brouhaha is really my fault in that I didn’t really explain what I meant when I said we “won’t be using the term ‘refactoring.’” I meant it really narrowly, but the way I wrote it I’m not surprised people interpreted it very broadly. All I was trying to say was that it is very likely that we will not be grouping IDE features that could be called “refactoring features” under a menu item that is entitled “Refactor” or “Refactoring.” That’s really it. We won’t have a menu item with the word “Refactor” in it. That’s all. We’re not going to be inventing new jargon to refer to the features, nor will we be hiding the fact that we support features that fall into the “refactoring” bucket. We just won’t have the menu item. (Actually, given the customizability of the VS IDE, you’ll probably be able to create the menu item if you prefer it.)
The VB team is not hostile to the concept of refactoring. Nor do we believe that all of our customers are unaware of the concept and/or have problems understanding it. It’s just that we felt we didn’t need to explicitly call out the fact that “Hey, the following features fall under the rubric of ‘refactoring.’” For example, symbolic rename is a feature that works pretty well on its own. We didn’t think we needed to explicitly link it to the abstract concept of refactoring to draw people’s attention to the feature or to convince them that it was useful.
The other reason I alluded to (and was, I suspect, the really sore point) is that for every developer who is immersed in the love that is refactoring, there are more than a few that aren’t. In fact, I’m one of them. I realize it may cost me some respect to admit this, but I’d never even heard of refactoring until C# added the feature to their IDE. I’ve never bought a copy of, much less read, Refactoring: Improving the Design of Existing Code. This does not mean that refactoring, as a way of life, does not have great merit or that I may not be woefully behind on an important trend in our industry. It just means that before C# added it, I didn’t happen to be familiar with the concept and, although I could be wrong here, I’m probably not the only one out there. (I’ll add that I like to think of myself as reasonably intelligent and well-informed, so obviously those two traits are not something I think are lacking in people who don’t know about refactoring.)
Given that there is some non-zero sized pool of developers out there who are not familiar with refactoring, the question then comes down to how to handle that. One way is to explicitly call out in the menu structure “Hey, these features fall into the category of ‘refactoring’ features.” and then rely on the user to say “Hmmm. ‘Refactoring.’ Never heard of it. I wonder what that is…” and start typing search terms into Google. A lot of developers, especially the professionals who are lucky enough to get to investigate new technology and new ideas as a part of their job, will do this. But there are a lot of developers out there who are going to say “Hmmmm. ‘Refactoring.’ Never heard of it. Crap, look at the time, I’ve got a lot to do before lunch…” and just move along. That’s because they don’t necessarily have the time or the extra available energy to spend exploring the nuances of Visual Studio, not because they are too stupid to figure it out. And, to be honest, for a lot of developers exploring interesting new trends in the computer programming industry is just not the main part of their job. They use VB or C# or C++ or whatever to get some part of their job done and move on. And if we can save them some time and energy by just saying “Here’s symbolic rename.” instead of saying “Here’s symbolic rename, but first I want to tell you about this little thing we like to call ‘refactoring’…”, then I think we’ve done them a favor, not treated them like idiots or children.
Now, if it was the case that helping out these developers would actually cost the rest of the developers something, then we’d have to really wrestle with the question. We do that kind of thing all the time, try and balance features between the different groups of developers that make up our customer base. But in this case, it really seemed like a no-brainer. If you know what refactoring is, you don’t need us to tell you that “symbolic rename” or “extract to method” are refactoring features. You already know that, we don’t need to drill it into your head. So, it’s not clear what harm there is in not having a “Refactoring” menu item as opposed to just showing the features directly.
Now, I realize that not everyone will agree with these sentiments, and that’s entirely OK. Despite the press we get, none of us at Microsoft really thinks we know it all. (Well, OK, maybe Don really does know it all, but he’s not always telling…) I think the feedback you’re all giving us on this issue is really great and we can continue this conversation as long as we need to. I hope this clarifies things a bit more, though.
Anand and Tom ask whether VB.NET is going to have refactoring support in Whidbey. The short answer is, despite what the PDC lab person told Tom, “yes.” However, the long answer is, well, a bit longer than that.
What C# is calling “refactoring” is actually a collection of related-but-separate code manipulation features in the IDE. Things that are included under this rubric are, I believe:
Some of these features are already slated to be included in the VB.NET Whidbey release, such as symbolic rename, and for others we’re open customer feedback as to which ones above they think are important. Or if there are ones you don’t see there, we want to hear about them as well! If you leave comments on this entry, I’ll make sure they get forwarded to Jay, the PM in charge of this area. (The more specific you are, the better. “Do everything that C# is doing.” is helpful, but “Reorder parameters is the most important to me because blah, blah, blah.” helps us even more!)
One thing that is likely, however, is that VB.NET won’t be using the term “refactoring” in the IDE to refer to these features. While that term is fairly common in some quarters, we believe there are lots of VB programmers who are likely to see a menu item called “Refactor” and just ignore it because they don’t know what the term means. We’d like to surface the features more directly so that they don’t get missed by our users. (If you disagree, feel free to give us a holler on that too!)
Now that I’m back from the PDC and my manuscript’s in, I’m starting to catch up on some of the backlog. One of the things I didn’t mention last week was that Cameron posted more information about operator overloading on his blog. Check it out!