XAML, much like HTML, doesn't require naming every element in
the markup. This is a *ahem* marked difference from the client app
dev technologies we've had in the past, like Windows
Forms and various forms of VB. In fact, just about every
client-side app dev technology, except maybe dialog resources in
Win32, has required that I provide a name for every on-screen
element that is backed up by a class of some sort.
The net result is you often end up with a namespace polluted
with Label1, Label2, Label3 etch. Those are completely meaningless
names, and show they're being named only because the
tool/platform/language requires it.
I remember back in the day, the "Label1" look was so offensive
to some, that they'd go and name every single label, group,
line and more on the form even if they never referred to them in
code. What an incredible waste of time for a
developer.
Naming in HTML
When I'm working in HTML I don't give an id to every paragraph
element, li, and span on the page. While you can, and it can even
be useful in some styling scenarios, it strikes me as a lot of
extra work. I do usually name divs, as I'm far more likely to refer
to them in a style or hunk of jQuery code. I like that HTML, and
the tools we use, give me an option here.
I follow a similar model when working in XAML.
Naming in XAML
When working in XAML, I follow the "don't name it until you have
to" philosophy for most elements. XAML is much like HTML in that
you don't need to name everything.
Naming an element on a UserControl-derived bit of XAML markup
creates a variable in the code-behind. Each one of those variables
takes up precious byte space in the compiled application. Each one
takes up a very small but real amount of time in the
InitializeComponent call. Each one adds more chaff to the
intellisense list. Each one creates a member variable which
can be referred to from outside your class, breaking
encapsulation.
I know some of the templates, and the designer, don't
follow this approach. I've put requests in to the teams,
so I'm optimistic that these will be changed in the future.
Normally I don't fight the IDE or templates, as those end up
becoming standards. In this case, however, I know lots of folks who
agree with me.
Naming everything in XAML can lead to future maintenance
problems. For one, it makes it harder to know what elements you're
actually referring to in storyboards or code-behind. If you're
working with a designer, they don't know at a glance which elements
they can safely remove when trying out a new design.
Elements I normally Name in XAML
Interactive UI controls like TextBoxes, ListBoxes, Buttons etc.
You can get away without naming these if you're using
commands/behaviors and a good pattern like MVVM, but I find naming
is helpful from a documentation standpoint. Not a requirement by
any means, but helpful.
Sometimes I'll provide an x:Name to a render transform inside an
element if I wish to use it in a storyboard. I find this (in most
cases) much nicer than using the dot-down syntax favored by Blend.
Both work, of course.
Anything which serves as part of a designer/developer
contract gets a name. Avoiding naming everything else
makes it much more clear which elements are part of that
contract.
Elements I normally do not Name
I usually don't name chrome elements: borders, lines, rectangles
and similar. I almost never name labels/TextBlock instances
With the exceptions in the previous section in mind, I never
name anything that won't be referred to in code or by other
elements. If you later decide you need to refer to them, it's
really easy to add the name in, indicating a contract that must now
be adhered to.
Summary
In WPF
and Silverlight, avoid naming elements which aren't
referred to elsewhere (code, animation, element binding). Adding a
name to the element helps indicate a dependency and serves as a
little bit of self-documentation. Adding a name to an element which
isn't referred to simply adds to confusion.
(nametag picture by Quinn
Dombrowski)
Related
