Naming and conventions in XAML

I think the naming and code/markup conventions in XAML is a bit unclear. This post will raise some of the issues.

I posted a new thread in the Silverlight.net forums about why there is no PART_ convention in Silverlight when this convention exists in WPF. I described the problem like this:

"In WPF there is a convention for TemplateElements in controls that distinguishes controls that must exist in a template from other controls. This means that if I edit a control template I know that all elements named PART_* must be in the template and all other parts I can remove or do whatever I like to.

When I looked in Silverlight Toolkit and the shipped controls there are no such standard, why? How should the user know which controls that must be in the template? I think it is sad that the framework doesn't look the same in all parts (yes I know that the Silverlight Toolkit is not in the framework, but realize that it will be a template and a teacher for many control developers). Is there a reason?"

I did not get a clear answer for why they have made it this way but the replies made me realize that PART_ convention can probably not be entered in the future because this will break the released code. And on the other side, in WPF the PART_ convention can not be removed because that will break the WPF code. I think the problem is that the two so similar frameworks differ in conventions and readability. What about the problem?

Yes, I know about the TemplatePart attribute and I know that the functionality does not change because of the naming convention. I think that the problem is that the tools does not use this information today. Tools like Visual Studio and Blend will soon be consuming the attribute but there are a lot of other tools that won't. This brings us to my second opinion.

I think this is a usability and design issue. If you read Framework Design Guidelines (K. Cwalina, B. Abrams) they have an important point when they say that the .NET Framework should "look the same" wherever you are. Therefore I think its a bad thing that Silverlight and WPF differs. A developer should recognize himself/herself when adopting a new area within the framework, and the framework code should be clear and readable. This is not a big issue and maybe I'm whining a little bit too much about this, but I think it is important that we create conventions for markup (XAML) in the same way that we use camelCasing and PascalCasing in e.g. C#. I have seen some unclear naming within the framework (in XAML), are there any conventions for naming and so on and do people use them?

Another part that is related to this is how you should name your members in XAML. Your XAML-file are compiled into the same container as the code behind (in the case of a UserControl) and there they will be members of that class. This means that if you name e.g. a Button "MyButton" it will appear as a member of the class with a field name "MyButton". In C# and in standard naming conventions fields should be named with camelCasing which means that the right name for MyButton should be myButton. The same thing for naming resources. Right now the naming is unclear and it differs within Silverlight and WPF and also between XAML and e.g. C#.

I think it is sad that Silverlight/WPF differs and I think it is important to create conventions for writing XAML. This is not about the functionality of the code you write, it is about the usability and the experience for the next developer that will read and try to understand your code. What do you think?