A couple of days ago I accidentally derailed the comments on Eric Lippert’s blog post about unused "using" directives. The reason that redundant code doesn’t generate a warning in Visual Studio is that it’s what you get to start with in Visual Studio. This led me to rant somewhat about other aspects of Visual Studio’s behaviour which sacrifice long term goodness in favour of short term efficiency. Almost all the subsequent comments (at the time of writing this post) are concerned with my rant rather than Eric’s post. Some agree with me, some don’t – but it’s only now that I’ve spotted the bigger picture behind my annoyances.
All of them are to do with names and the defaults provided. I’ve blogged before about how hard it is to find a good name – it’s a problem I run into time and time again, and the ability to rename something is one of the most important refactorings around.
If you don’t know, ask
Now if it’s hard to find a good name, it stands to reason that anything the IDE can generate automatically is likely to be a poor name… such as "Form1", "textBox1" or "button1_Click". And yet, in various situations, Visual Studio will happily generate such names, and it can sometimes be a small but significant pain to correct it.
The situation which causes me personally a lot of pain is copying a file. For C# in Depth, I have a lot of very small classes, each with a Main method. When I’m evolving an example, I often want to take the existing code and just change it slightly, but in a new file. So I might have a file called OrderByName.cs containing a class called OrderByName. (I agree this would normally be a bad class name, but in the context of a short but complete example it’s okay.) I want to just select the file, hit copy and paste, and be asked for a new filename. The class within the file would then be renamed for me as well. As an aside, this is the behaviour Eclipse has in its Java tooling.
In reality, I’d end up with a new file called "Copy of OrderByName.cs", still containing a class called OrderByName. Renaming the file wouldn’t offer to rename the class, as the filename wouldn’t match the class name. Renaming the class by just changing it and then hitting Ctrl-. would also rename the original class, which is intensely annoying. You’re basically stuck doing it manually with find and replace, as far as I can see. There may be some automated aid available, but at the very least it’s non-obvious.
Now the question is: why would I ever want a file called "Copy of OrderByName.cs"? That’s always going to be the wrong name, so why doesn’t Visual Studio ask me for the right name? It could provide a default so I can skip through if I really want to (and probably an "Apply to all items" if I’m copying multiple files) but at least give me the chance to specify the right filename at the crucial point. Once it knows the right new filename before it’s got a broken build, I would hope it would be easy to then apply the new name to the class too.
The underlying point is that if you absolutely have to have a name for something, and there’s no way a sensible suggestion can be provided, the user should be consulted. I know there’s a lot of discussion these days about not asking the user pointless questions, but this isn’t a pointless question… at least when it comes to filenames.
If you don’t need a name, don’t use one
I’m not a UI person, so some of this section may be either outdated or at least only partially applicable. In particular, I believe WPF does a better job than the Windows Forms designer.
Names have two main purposes, in my view. They can provide semantic meaning to aid the reader, even if a name isn’t strictly required (think of the "introduce local variable" refactoring) and they can be used for identification.
Now suppose I’m creating a label on a form. If I’m using the designer, I can probably see the text on the label – its meaning is obvious. I quite possibly don’t have to refer to the label anywhere in code, unless I’m changing the value programmatically… so why does it need a name? If you really think it needs a name, is "label1" ever going to be the right name – the one you’d have come up with as the most meaningful one you could think of?
In the comments in Eric’s blog, someone pointed out that being prompted for a name every time you dragged a control onto the designer would interrupt workflow… and I quite agree. Many of those controls won’t need names. However, as soon as they do need a name, prompting for the name at that point (or just typing it into the property view) isn’t nearly such a distraction… indeed, I’d suggest it’s actually guiding the developer in question to crystallize their thoughts about the purpose of that control.
Okay, this has mostly been more ranting – but at least it’s now on my blog, and I’ve been able to give a little bit more detail about the general problem I see in Visual Studio – a problem which leads to code containing utterly useless names.
The fundamental principle is that I want every name in my code to be a meaningful one. The IDE should use two approaches to help me with that goal:
- Don’t give a name to anything that doesn’t deserve or need one
- If a name is really necessary, and you can’t guess it from the rest of the context, ask the user
I don’t expect anything to change, but it’s good to have it off my chest.