Mobile Zone is brought to you in partnership with:

I’m a passionate software developer. I was born in Québec, Canada. I work at Mirego; a company specializing in mobile applications. I am the Windows Phone and Windows 8 specialist. My friends describe me as a Microsoft Evangelist. I love C# programming with Visual Studio, the .NET Framework, the Windows Phone and the Windows 8. When I’m not in front of a computer, my hobbies include playing bridge, poker and other card games, biking, reading technology news. Sébastien is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

XAML Coding Convention

12.22.2012
| 2877 views |
  • submit to reddit

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-onReSharper, 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.

image

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!

Published at DZone with permission of Sébastien Lachance, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)