I’ve had a lot of people disagree with me on this one but I just ran into another case where this was incredibly annoying and proved it’s importance once again deeming it blog worthy.

Naming every object in your XAML is just good practice. I think we can all agree on that. Of course it’s just a matter of how much time we have to be tedious and do this. Naming is what unites teams and allows multiple people to work together on a project independently. It also allows markup to be self documenting. (Comments in XAML in Blend is a difficult thing because they read better when declared before markup but do not travel with markup when they are moved via the Objects and Timeline Panel in Blend.)

It is the naming convention where we usually have some controversy. So far I’ve worked with a lot of companies who have their own naming conventions that are born out of the companies internal platform specifics. Another legacy implication on naming conventions is the notation that the developers adopt. This is just about a religious issue that is always an uphill battle.

What do I recommend… I always recommend redundantly naming your object type in the name. For example “StopButton”, “StopButtonStyle”, “StopButtonControlTemplate”, “StopButtonStoryboard” etc.

First, I always explicitly spell out these things to follow .NET framework general naming conventions. For those of you out there who want to abbreviate things with “btn”…. stop it. Unless you can package yourself up in your code so you can translate for me or can send me back to school to learn a standards defined pidgin code. Nothing aggravates me more than having to try and figure out what people are alluding to when there really isn’t a strong technical argument for reducing characters in code in .NET.

Second, providing an object type as a suffix solves a huge problem that developers don’t have to experience as intimately as designers/integrators using Blend have to… In Blend we use the Objects and Timeline panel extensively. The result is that we are very dependent on two elements that are displayed in this panel. The icon and the actual name text.

Now take this case for instance:

Here I am creating a custom control template for a TreeViewItem… You know its a control template because I can see it in the title. That’s not what I want to focus on here. More importantly note the item named “Expander”. This is the items name not for an Expander control but for a ToggleButton… Which there is no way for me to know except for to “View XAML”. Not only do I not have a clear picture of the structure of my control, but this a red herring that is making me think that TreeViewItems have Expanders.

Ok now here is the same structure in XAML with the elements named more clearly:

With this I can understand not only that Expander is a ToggleButton, but also that Bd is a Border and it is used for the Header of a TreeViewItem and I now know that the ItemsHost is laying out using a StackPanel. 3 words displayed in a TreeView and a world of difference in understanding the structure of a control.

What could make this better? Expression team if you are listening. Tooltips with some valuable information in the Objects and Timeline panel. Imagine mousing over an object and seeing the Object Type and all the applied properties… A quick summary of what that object is without having to browse the Properties Panel. Should be a simple addition… It’d be nice to see these tooltips in the Artboard as well.

Design time comment attributes would be a thing of beauty as well… For example:  d:DesignComment=”This border element is here for a reason don’t delete it.”