XAML Best practices

In this chapter we will talk about formatting XAML code, issues regarding performance and naming conventions. This section can and will be expanded as further knowledge will be collected.

Formatting

• x: Name or x: Key should always come first.
  
• Every Attribute should be stacked over another for readability, except maybe for similar ones, but this is not obligatory. E.g.: HorizontalAlignment – VerticalAlignment or Width – Height
  
• Adding comments.
  

This is one of the most important things on how to write clear code. With the support of these comments you can save up time on searching and asking around. Try to describe as best as possible the place, function, purpose of this object.

• Remove unnecessary code pieces.
  

Not only makes it the code clearer & more understandable, you are also improving the performance when not loading unneeded elements.

Naming Conventions

The x:Name is used to give a unique name for an object, this attribute is valid throughout the whole XAML code with one exception, it’s not valid in a ResourceDirectory. But there is also the attribute x:Key which is mainly relevant when naming styles, brushes or templates in a ResourceDirectory and that is in our case the UBIKThemes file, this attribute is only valid within this file. Use explicit language when naming for example: NOT stkpnlProperties more like StackPanelProperties! It could force you to rethink about the structure of your object when placing the true purpose of it in the name in order to minimize your element count. You DON’T have to name every object in your code, just the ones with e.g. an important feature.

Performance

Diminishing the performance should not be the first priority but it also shouldn’t be the last. You should always think about retaining readability and consistency in your code by adding comments and using clear and significant code. But you also have to keep in mind that more code and lines mean more compiling, this can decrease the performance of your whole application. Just try to keep a good balance between these two factors in order to ease the life of customizers. They’ll surely stumble across your code in a few months and will maybe have a hard time to finalize a ten-minute task because they have to find out what every piece of code exactly does. Here are some examples which support the increase of performance.
For example:

• If you use the same resource on more than one XAML file, consider defining it in UBIKThemes (Resources Folder -> LocalState/XAML) rather than on each page.
  
• Don't define UI elements you don't need for composition and use the default control templates whenever possible (these templates have already been tested and verified for load performance).
  
  

Useful links for inefficient XAML code:

• https://www.codemag.com/Article/1509091/XAML-Anti-Patterns-Layout-SNAFUs
  
• https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/optimize-xaml-loading

Using 'NextLevel' bindings

Performance can be impacted by attempting to show multiple levels of data (ie. child data, from the parent object) outside what is delivered by UBIK by default.

For an in-depth explanation, and guidance on how to implement such functionality safely, please refer to this page Object hierarchy in XAML: NextLevel, ParentLevel, LinkedLevel.

Testing of UI

XAML can be sometimes very weird, there are dependencies or default values that you don’t see immediately. So, a good way to prevent millions of fixes for the customer, because the environment, different device or even a different windows version destroys your UI, is to write a test plan where you test your implementation. It’s important to see exactly your controls in action on their own and acting with each other, so you can prevent doing lots of ‘easy’ fixes.