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.
Conclusion
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.
Jon Skeet's coding blog 
Resharper can aid a bit with file rename – there is an option – sync class name with filename. So you usually just need to rename class inside a file.
LikeLike
Good points. I have often also wondered the same about the naming. The IDE should support your workflow. Having been using eclipse for a while on a project I am working on, when I switch back to Visual Studio I sometimes think “seriously, how can VS not do this, I never noticed this before.”
LikeLike
I whole-heartedly agree with your post/rant. I don’t think I can add more to how you’ve put it.
However, another thing I would love to see is if you move a file to a deeper folder in your project (or even in a separate project), the namespace should also be updated (automatically and not via prompt). I could see this as a setting in the IDE. I mean, when you create a class in a folder, it uses the name of the folder as part of the namespace hierarchy anyways, so why not during a file move.
LikeLike
100% agree that it’s *very* annoying. Jayson’s comment about namespaces is also a good idea (although R# helps with this a lot).
LikeLike
I fully agree, but using R# seems to help already.
However, I think that using the Label as example is a pretty bad choice. When it comes to localization, the label will need a unique ID somehow, so stating a Panel or whatever may be a better choice, and even those may require localization support (other size, other position due to right-to-left language, or whatever the reason is). In the end only a few controls – if any – end up without requiring a name…
LikeLike
Not giving controls names by default, and then only giving them a name when you explicitly set a name sounds like a good idea to me. It certainly enforced better design than making the user remember to check that box which prevents the control from being public on the forms class (I don’t even remember what it’s called!)
LikeLike
Actually, due to that I tend to copy the class code inside the file, rename it there and use resharper to move the code to its own file.
That way I avoid the nasty “Copy of” filename, and it all ends up nice and tidy :)
LikeLike
Hey Jon, big fan here.
Regarding Windows Forms controls, they don’t have to be named. In the properties for each you can set GenerateMember to false and they will be created as local variables in InitializeComponent(). It’s still a small pain to set this for each control, but better than coming up with some stupid name like “_nameLabel” for each.
Labels and Groupboxes almost never need names. It would be nice if these defaulted to ‘false’ for GenerateMember.
LikeLike
@Matt: The control is still named, even if a member isn’t generated. (Try clearing the Name property…) But yes, with GenerateMember as false it’s at least *better*.
@Lucero: Good point about i18n, although many in-house apps will never need to be translated. A container control would definitely have been a better example.
LikeLike
That’s one of the things I like about asp.net – you don’t have to specify a name (ID) on controls if you don’t want to. I’m of the opinion that an ID should only be specified if you intend to refer to it from another control or the code-behind – it really helps reduce clutter.
LikeLike
100% agree with the file copy issue, VS could easily do a better job
It would actually be great (and easy to implement) if we had an option in VS to specify the behavior we prefer:
let VS decice the control’s name when dragging to a form
or be asked for the name every time we drag a control to a form
(I’d personally choose the 2nd option and favor naming rather than workflow)
LikeLike
Wait, textBox113 isn’t a good name? Crikey.
LikeLike
It’s worth pointing out that Interface Builder doesn’t assign names to UI controls. They don’t actually have name. Instead you create (possibly multiple) bindings from controls to IBOutlet properties on the owner class.
LikeLike
To me, it still seems that VS user interface was designed by people who don’t use VS themselves. Some of the user interfaces are so bad where I tell myself “There is no way in hell, I could have designed this user interface any worse, even if I wanted to”. Examples of the top of my hat: 1) adding a reference takes forever even if you know what you want to add, 2) the options dialog cannot be resized 3) there are hundreds of keyboard shortcuts under “keyboard” in the options dialog, but it shows only 3.7 at a time, seriously, WTF? (the user interface designer of that window must be fired)
LikeLike
I see a need for naming every control. It is perhaps a contrived example, but suppose I have a control on a complex form and for some reason the control is not visible in the design view. Suppose I need to access that control to delete it or otherwise modify it. If I had to dig around looking for the control because it didn’t have a name that I could use to pull it up in the properties window, it would be a huge hassle.
LikeLike
An added annoyance is when you use VS-integrated source code control like Ankh. (I can’t profess to be an expert on it because I ditched integrated SCC completely because of annoyances like this).
Copy a file, get a “Copy of – X” filename, and SCC thinks you want to add “Copy of – X” to version control. Juggle these files around and you end up getting a very confused SCC system. It’s worse when you do it with folders, if memory serves.
LikeLike
I agree
The most annoying feature of the visual studio aspx editor is generating a name for controls when all I did was copy existing controls and added them somewhere else on the page.
LikeLike
John,
You don’t need names
Controls.Add(new Label() {Location = new Point (0,0), Text=”NoName”});
Goes as well in WPF as in Forms
For your father
Controls.Add(New Label With {.Location = New Point(0, 0), .Text = “NoName”})
See you,
Cor
LikeLike
Cor: I know that WinForms itself doesn’t require names. My point is that the *designer* forces you to have names.
LikeLike
maybe visual studio should read your mind and write your code for you too!!
LikeLike
I saw a few suggestions in the comments of how to get Resharper to help with the copy file, but I did not see the one I think is simplest. Go to the type you want in to copy and use Resharper’s ‘Copy Type’ command. It will ask you for the new type name and sync the filename with that.
I generalize the naming problem in Visual Studio with a lot of other Visual Studio issues. To me Visual Studio tries to “help” too much. I find myself undoing a lot of what it tries to do for me and therefore doing more work if it did not do it. In some places I can easily get around its attempts at helping. In others, such as default names, I can’t. I would rather turn off its attempts at “helping”.
LikeLike
I’d rather have to rename than be presented with a modal dialog.
LikeLike
It’d be nice if they (Microsoft) invested a single developer to add some form of learning to the renaming and used that.
For example my forms are called “FormMain”, “FormAbout” and so on. But I’ve seen people use “frmAbout”.
If using some form of learning is taking it too far, just a simple rules setting based on regex would be enough.
5 clicks and an occasional 5 second wait for the dialog is what I’m confronted with every day with TFS, just to add a new class.
LikeLike
You clearly don’t write much ASP.NET, Jon, because if you did, the top VS naming offense would be when copying/pasting asp.net controls in the markup. If I copy/paste my FirstNameLabel and FirstNameTextBox controls so I can quickly make a label/textbox for the last name, VS has the nerve to change my almost perfect IDs to the useless “Label1” and “TextBox1”. I recently discovered there is an option to turn this off, however, but it’s buried pretty deep. (tools->options->text editor->html->miscellaneous->Auto ID pasted elements in Source View, if anybody is interested).
I’m glad you wrote this blog post…You alluded briefly to this in C# in Depth when describing your hatred of the ControlName_EventName default in VS…It was just about the only thing in the book I disagreed with, and I’ve been yearning for more explanation. I dislike the fact that it ends up breaking camel case/pascal case conventions, but I see that as less of a problem than forcing my SaveDocument() method to have sender and eventargs parameters. I rarely look at the event wiring generated by the designer, so I think having a SaveButton_Click(…) { SaveDocument(); } gives the reader a much better sense of where SaveDocument() gets called and what happens when SaveButton is clicked.
I’m also not sure I like all your ideas of having VS constantly ask me for names when I’m designing a UI. What it should really do is just make it easier to change the names once I’m in the mood to do so…That properties window seems like a mile away sometimes. I also wouldn’t mind the behavior the designer has for the menu items, where once you change the text of the menu item it makes its best guess at a reasonable name.
LikeLike
@Jared P: The idea would be that the designer wouldn’t ask you for names all the time – but it wouldn’t give you bad default names either. It would just leave the controls anonymous until you actually had to refer to that control somewhere else. At that point you’re likely to be in a good position to choose the name anyway.
LikeLike
In that case I’m on board! Where do I sign the petition? On second read I realize you made that perfectly clear in your blog post. I do wish you would explain your dislike of ControlName_EventName naming a bit more…Like I said, it’s about the only thing I’ve ever disagreed with you on, and I’m smart enough to know I’m not smart enough to lightly disagree with Jon Skeet! ;)
PS…I Loved the book, I’ll be first in line when the next one comes out. Now if I can only convince you to write CSS in depth, Javascript in depth, T-SQL in depth, .NET Framework in depth, and a few other topics that could use similar treatment!
LikeLike
@Jared: Maybe I’ll go into the naming thing in another post. I may well not be able to convince you, admittedly. I have a few ideas as to how it could be *really* nice now that we’ve got lambda expressions…
LikeLike
John, you are right they did fix this in WPF. Elements only have a name if you specify them to have x:Name=”Name” in WPF and you only need to specify it if you want to someway reference that element elsewhere in the XAML or in the code. It is much nicer not to type ‘l’ into intellisense and get a list of all the labels you put on the form.
It still is annoying in WinForms, but then again many things are in WinForms. The automatic naming puts you in an awkward position because for things that have labels you have to either specify a name like NameFieldLabel that gets annoying to type or and maintain or just leave it and ignore it. Both of which are less than ideal. Unfortunately, I don’t think there is really no way easy way to correct this in WinForms because the designer generated code doesn’t do things in atomic blocks for each control. I think it’d create a lot of complications. I hate going back to WinForms after using WPF precisely because of issues like this.
I also agree completely with the rename of files in particular. There are many lessons that the VS team could take from Eclipse and its plug-ins that would make Visual Studio better. When I transitioned back to .Net Development I found myself constantly hitting Ctrl + Shift + O to organize my imports to try to get my usings organized. Its simple things like that can really improve developing on the platform. Thanks for pointing out one that has also bothered me.
LikeLike