XAML Naming Conventions in Xamarin Forms

While developing applications, one of the things that help maintain the quality of your code is adhering to the naming conventions of the programming language you are using. As Xamarin Developers there are predefined rules that we usually follow in our C# code. But what happens with our XAML?

Since there’s no pre-defined naming convention to follow, what we usually see in most XAMLs is something like this:

The problem with this is that it makes our XAML really hard to read. In this article, I’ll show my personal XAML conventions which I usually follow when creating XAML UIs.


Let’s start


1. Add each property in one line and leave a line between elements

Instead of:

Do:

Why: Is easier to see the details of each element.


2. Use PascalCasing when defining x:Name and AutomationIDs

Instead of:

Do:

Why: No particular reason, just personal preference.


3. When defining a x:Name/AutomationIDs use explicit names, following this format [ElementName][ElementType]

Instead of:

Do:

Why: if you use short names when someone reads your code they need to figure out what’s the abbreviation meaning.


4. Order the attributes alphabetically except for the x:Name and Attached properties those need to be at the top

Instead of:

Do:

Why: Easier to read.


5. When using Grids, use Inline definition for Column/Rows

Instead of:

Do:

Why: It makes your XAML shorter.


6. Don’t set default property values

Instead of:

Do:

Why: It makes your XAML smaller and gives you better performance.

Tip: If you want to see what’s the default value of a property, you can do a right click on the property then click on Go to Declaration, if there is a default value it will be specified there.


8. Use a specific order for the properties within the body of your Element

I usually use this one for Effects, Behaviors, Triggers, and Gesture Recognizer.

Instead of:

Do:

Why: Keeps consistency.


9. Use a short closing tag for those elements that have no properties within the body

Instead of:

Do:

Why: It makes your XAML shorter.


10. Add tabs to elements within elements

Instead of:

Do:

Why: Easier to read.


11. Split your styles into different files, instead of having them all in just one file

For example, if you have Colors, Global Elements, Converters, Explicit styles create a new file for each one and load them in your App.xaml file.

Ex.

Why: Is easier to find styles.


12. Define your Styles using Pascal Case and the format [StyleName][ElementType][Style]

Instead of:

Do:

Why: No particular reason, just personal preference.


Final thoughts

These are the XAML conventions that I like to use, but it doesn’t mean that these are the ones you should use. It just means you need to start thinking about using XAML conventions. Define the conventions you want to follow and use them, that way when someone reads or needs to maintain your XAML it will be easier to read and understand.

Happy coding!

You may also like

6 Comments

  1. I would suggest using the extension XAML Styler to help you capture some of these rules in a file which can be shared with other developers on your team. It may not have fine grained settings for all of these things you mentioned, but it does have a few of them.

  2. Hello There. I found your blog using google. This is an extremely well written article.
    I’ll make sure to bookmark it and return tto read
    more oof your userful information. Thanks foor the post.
    I’ll certainly return.

  3. Wonderful job right here. I definitely enjoyed what you had to say. Keep heading because you absolutely bring a new voice to this topic. Not many people would say what youve said and still make it interesting. Well, at least Im interested. Cant wait to see more of this from you.