XAML coding convention
Over the past year, I have built my own coding conventions for C#. I also always manage to convince my colleagues to follow my coding convention if they don’t already have one. I’m a real freak about following coding conventions; if I see someone modifying one of my files and not following my conventions, I might have trouble sleeping at night (ok, not that much, but…).
With the help of the great Visual Studio add-on ReSharper, it’s easy to format code with rules. You only need to press Ctrl-E/Ctrl-C to format a document. ReSharper is a must have tool for Visual Studio.
For the past two years, since the release of the Windows Phone platform, I have been using the XAML language to program my user interfaces. Finding coding conventions for C# is pretty easy, but for XAML, it was a bit more of a challenge. My first move was to check the default Microsoft projects, but I concluded that even they are a bit messy even for today.
Here is an example of a WIndows Store Grid App project:
<ListView.GroupStyle> <GroupStyle> <GroupStyle.HeaderTemplate> <DataTemplate> <Grid Margin="7,7,0,0"> <Button AutomationProperties.Name="Group Title" Click="Header_Click" Style="{StaticResource TextPrimaryButtonStyle}"> <StackPanel Orientation="Horizontal"> <TextBlock Text="{Binding Title}" Margin="3,-7,10,10" Style="{StaticResource GroupHeaderTextStyle}" /> <TextBlock Text="{StaticResource ChevronGlyph}" FontFamily="Segoe UI Symbol" Margin="0,-7,0,10" Style="{StaticResource GroupHeaderTextStyle}"/> </StackPanel> </Button> </Grid> </DataTemplate> </GroupStyle.HeaderTemplate> </GroupStyle> </ListView.GroupStyle>
First of all, there are not any empty lines, and secondly the button has attributes on separate lines, but for the TextBlock elements, the attributes are on the same lines without any order.
With time, I developed my own XAML coding convention that I would like to share. One of the reasons that I developed my own XAML coding convention is I don’t like to use the Properties window, because it is hard to have an overview of the properties that are not set to default.
My coding convention is resumed in 5 points:
1- Put empty lines between elements.
Don’t be afraid to put empty lines. It makes reading the code easier.
<Grid Height="250" VerticalAlignment="Top"> <Image Source="{Binding FeatureArticle1.Thumbnail}" Style="{StaticResource ImageThumbnailStyle}" /> <StackPanel Style="{StaticResource StackPanelSummaryStyle}"> <TextBlock FontSize="22" Style="{StaticResource TextBlockAuthorStyle}" Text="{Binding FeatureArticle1.Author}" /> <TextBlock FontSize="26" Height="70" Style="{StaticResource TextBlockSummaryStyle}" Text="{Binding FeatureArticle1.Title}" /> </StackPanel> </Grid>
My exceptions are the Grid.ColumnDefinition and Grid.RowDefinitions, because they only have one line attribute.
<Grid.ColumnDefinitions> <ColumnDefinition Width="200" /> <ColumnDefinition Width="200" /> </Grid.ColumnDefinitions> <Grid.RowDefinitions> <RowDefinition Height="200" /> <RowDefinition Height="140" /> </Grid.RowDefinitions>
2- Put one attribute per line.
<TextBlock FontWeight="Bold" Foreground="White" HorizontalAlignment="Right" Margin="0,0,12,0" Text="{Binding ArticlesCountText}" TextWrapping="Wrap" />
3- Order the attributes alphabetically.
<Image Source="/Assets/Shares/NeutralImage.png" Height="125" HorizontalAlignment="Center" Width="125" Stretch="UniformToFill" VerticalAlignment="Center" />
Some will argue that Height and Width should be side by side or on the adjacent line, but I still prefer the alphabetical order, because it is much easier to read when you know what order your definitions are in. Also, if there is an element with many attributes, it is much easier to check whether an attribute is missing.
4- Put the attached properties at the beginning and in an alphabetic order.
<Button Grid.Column="1" Grid.Row="2" Command="{Binding ShowWriterCommand}" CommandParameter="{Binding WriterAshley}" Style="{StaticResource HubTileButtonStyle}" />
The Grid.Column / Grid.Row are the classic examples.
5- Definition of styles can be less strict.
When I’m creating styles with Expression Blend, I tend to leave them as-is when they are big. It is more about saving time than anything else. However, when a style is small, I don’t put empty lines and I put the properties in an alphabetic order like this:
<Style x:Key="GridFeatureStyle" TargetType="Grid"> <Setter Property="Height" Value="194" /> <Setter Property="VerticalAlignment" Value="Top" /> <Setter Property="Width" Value="194" /> </Style>
Conclusion
It might not be the perfect solution for you, but if you do not have one, my convention is a good start especially if you are sharing code with colleagues.
My motto about coding convention is the following: it is better to have a coding convention than not having one!
Happy coding!
PHenry
Nov 26, 2012 @ 15:25:36
DOH! I have always agreed with your blogs and loved your information. Buuuuuut, I guess even the BEST relationship have hiccups and speed bumps. 🙂 haha This is where we differ, but I’m guessing you’ll find many people differ on formatting conventions.
Since devs are getting ever growing LCDs, I don’t see a problem with multiple attributes on one line, in fact, I prefer seeing the bigger picture if at all possible. I find I can do that better if I can see “the whole control at once, in context with what’s around it.” This usually means very few (if any) empty lines. But that’s just me.
And no convention discussion would be complete without the tabs vs spaces question? Where do you stand on that?
ArchieCoder
Nov 26, 2012 @ 19:08:28
Hahaha, you have a point here!! Right now, I can feel lucky that all the work I have done so far, I have alone for the XAML files 🙂
Concerning the tabs vs spaces, I never understand why there are so many battles over the year. When I installed VS, I don’t play with the tab/space setting. It uses tabs and it work perfectly! I don’t know why people like spaces. Do you? 🙂
PHenry
Dec 24, 2012 @ 13:08:58
I believe it’s from of the UNIX/C/C++/old text editor days, long before our fancy WYSIWYG IDEs.
Interesting side note, you can usually tell an older/C++ developer by two give-aways, underscores prefixing private vars and militant about space over tabs! (and to go along with this, you can usually tell an ex-Microsoft by the m_ prefix for private vars).
OOM
Dec 24, 2012 @ 17:29:11
Regarding point #3 –
you should notice that sometimes the order of attributes is important.
See for example – http://www.nickdarnell.com/2009/11/xaml-attribute-order-matters/
So always ordering them alphabetically can lead to unwanted results.
archiecoder
Dec 25, 2012 @ 01:24:58
Interesting, I should try that on the Windows Phone app. I think the model command has changed and it is also different on WP.
OOM
Dec 25, 2012 @ 16:29:46
It’s matter for other attributes as well, not only the Command and CommandParameter.
Another example can be seen in the following link, this time attribute order of SelectedItem and ItemsSource.
http://weblogs.asp.net/dixin/archive/2009/12/17/the-order-issue-of-xaml-attributes.aspx
archiecoder
Dec 25, 2012 @ 16:57:30
You’re right, I tried with a WP8 sample and the ListBox control is sensitive to the order!
Thanks for the info! I’ll be careful about that.
jianghongfei
Jan 07, 2013 @ 10:36:43
Hi, in visual studio, TOOLS > Options > Text Editor > XAML > Formating > Spacing, there’s a radio button “Position each attribute on a separate line”, which will give you the expected format. Although the attributes are not in alphabetical order, it seems better. Have you tried this?
archiecoder
Jan 07, 2013 @ 10:53:04
Oh cool! I didn’t see that option. I use ReSharper all the time and it already has this option in the Cleanup my code feature.
Thanks for the info, it might be useful for the other developers.
ArchieCoder