With Silverlight 3 just around the corner, developers and designers are now starting to work in harmony with both layout and code in Blend and VS2008.
Every developer who starts off into coding has their own opinion on how their code should be structured and formatted.
This comes from Martin Fowler’s classic book Refactoring:
There is another user of your source code. Someone will try to read your code in a few month’s’ time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important. Who cares if the computer takes a few more cycles to compile something? It does matter if it takes a programmer a week to make a change that would have taken only an hour if they had understood your code, so clearly the need to present code, especially large amounts of XAML (and yes it can get quite big!) is becoming more a requirement.
When it comes to writing in XAML for Silverlight or WPF, being a fairly new technology, there aren’t too many opinions about talking best practices in comparison to other launguages/markup.
In fact, the definitive guide for XAML guidelines is Jaime Rodriguez’s (site) best practice web cast series and the resulting whitepaper (pdf).
XAML practices series, part1 , XAML practices series, part2 , XAML practices series, part3
Jaime’s whitepaper is a must read for anyone in the Silverlight WPF/E /WPF space.
XAML Formatting
First and foremost, I think formatting is the number one concern.
- Any attributes should be on a separate line,
- x:Name should come first, and you should if possible always have an x:Name for every element and related attributes (such as HorizontalAlignment and VerticalAlignment) should be grouped, eg Layout should be group together, text and text styles grouped etc.
Above is a basic XAML Layout to take a name and an email address, as you can see the XAML is quite minimal, but is a little hard to read with all the attributes, taking a closer look at the same code below Figure-A and Figure-B, show the difference between having all the attributes on the same line versus on different lines. In my opinion, Figure-B is much easier to digest than Figure-A.
Figure-A
Figure-B
By having the x:Name first, you can quickly identify what the element is. Once you find the object you are looking for, you can then quickly identify related objects since they are grouped together (such as RadiusX and RadiusY, Width and Height, and HorizontalAlignment and VerticalAlignment).
The biggest complaint about Figure-B is “wasted space”. The code inflates from 8 lines to 30; however, to Martin Fowler’s point, it’s not about you or the computer, it’s about other people being able to read and quickly assimilate to your code.
x:Name is your friend.
Name everything for later.
Try to specify an x:Name attribute for every element in XAML. If nothing else, this will make you think if you really need the object. For example, at times it’s tempting to embed a panel within a panel to achieve a specific layout. After refactoring I find that if I tweaked a margin or used a different kind of panel, there would have been no need for the extra panel. Forcing an x:Name on an object really makes you think of the purpose of that element.
Describe Elements for later reference
Instead of pre or post-fixing element names, give them a descriptive name. Instead of:
- btnSubmit use SubmitButton,
- grdMainContent use MainPanelContent,
- layoutNavPanel use NavigationPanel.
Programmers like using the pre-fix because you can quickly see all of the same type when using intellisense, and you can easily identify the type of an element. Admittedly, I’m from the designer side of things and when i see code with prefixed terminology I have to follow back that cryptic understanding of what its actually doing, and with more and more designers working in Blend as opposed to other tools, they will have to have a better understanding over the prefix’s, so as a developer keep the prefixes descriptive enough that a developer OR a designer can understand (think stkPanel=StackPanel or me=MediaElement).
Lastly, give all panels the same post-fix because you never know if you will have to change the type of a panel.
I assure you, it’s an enormous pain, and large risk, to change the x:Name in a project. For example imagine having to change “BufferGrid” to “BufferCanvas” to “BufferStackPanel”. Not only do you have to change the XAML, you have to ensure all instances in the code are changed too. Better to go with the generic “BufferPanel” and be done with it.
If possible its best if you try to group prefix your canvases so its easier to read later on when you introduce new panel’s or canvases inside Blend.
Steve
