Since the dawn of time (OK, since Visual Basic 1, but that was a long time ago in computer time) designers have been automatically assigning names to controls. Plop a button on a form and it was given a wonderful name like "Button1". But at least it got a name. You had no control over this in Visual Basic. Controls all had to have names, so even if you had a form that contained nothing but lots of static labels your code still had access to Label1 through Label200.
Windows Forms in VS.NET 2005 changed that a bit. We still required names on controls because too many things broke if we didn't name all the controls with unique names. However, we allowed you to flip a bit that would cause the code generator to generate the variable as a local rather than as a member variable. Now all your labels and static images could stay the heck out of your Intellisense drop downs. There was much rejoicing, except by the QA team whose test matrix doubled in size.
Names on controls in WPF are optional. If a control isn't named, you can't write code against it without searching for it in the visual tree. This is a good thing because in WPF forms and pages may have a ton of elements and only a few of those are directly programmed against. You may have noticed that Cider supports empty names, so if you clear the name field we don't generate an error. We're pretty happy with that part.
What we're not clear on is when we should actually provide a name for controls. Conventional thinking says that we should give everything the idiotic but familar "Button1" style names whenever a control is dropped on the designer. The challenge with this is that names in WPF have a runtime cost, so if you have lots of controls that have names you're not using you're paying a runtime penalty. The power of XAML means that you will probably have a lot less code to handle events in a WPF application, so the need to have programmatic variables to access controls is less.
Here are some of the ideas we've been throwing around:
Name Everything
This is exactly what Windows Forms does today. Everybody gets a name, and if you don't want it you need to clear it out of the property window yourself. Each name has an associated runtime cost for WPF to wire the control to a member variable. This will be familar for existing Windows Forms and VB 6 customers, but it takes additional work to write a well optimized WPF application. Also, if you have many elements on your page UI that lists those elements, such as the property window and Intellisense, become more cluttered.
Name Nothing
The zen opposite of naming everything is to just name nothing. Nothing gets a name when you drop it on the page. If you want to program against it, you first give it a name. We could be smart here and if you wired an event through either the property window or through by double clicking on the control we could generate a name for you on the fly. This breaks the usability of the event drop-down windows in the code editor, however, because unnamed elements won't show up there.
Name Nothing and Prompt
If you drop a button on a page and it doesn't get a name, then you double click and we automatically give it a name, what name do we give? That's right, "Button1". Sure, you can rename it later, but the event method we wire to the control will be named something like "Button1_Click". Yuck. Yes, we have thought about allowing the rename refactoring code to rename event methods too, but that's an inexact science we don't know if we can get right in all cases. One option here is to interrupt the flow with a modal dialog and ask you what name you want. We would then name the control with the value you provided and use that name when generating the event handler method. Clean, but that modal dialog is going to get old fast.
So, what do you think? Should we name automatically like we've always done? Should we name opportunistically? Should we stick a big fat modal dialog in your face and ask you what you want things to be named?