My MAUI Day talk - part 2

Part one is here. (You should probably read that first. ??)

Aside: What does good XAML look like? - If you've never thought about it before, take a minute to consider this. Barely anyone has a good idea.

It's not "just XAML" or "only a markup language".

What we put (type) in files that become part of an application and which we later need to read and possibly edit all have a lot in common. Yes, C# and XAML look very different and are typically used for different tasks and in different ways, but there are some truths that hold for both (or any programming language.)

For any "code" that we'll have to maintain, we want it to be:

• Easy to write
• Easy to read (and understand)
• Consistent
• Well formatted
• Unambiguous
• As concise as possible without inhibiting understanding
• Without unnecessary duplication or redundancy

There's nothing controversial in that list. Is there?

Nothing you'd disagree with? - If there is, please leave a comment.

But, does that sound like most XAML you've ever seen?

I doubt it. And I think that's a problem.

If you think about it for a moment you'll start to question this too.

Above I got you to think about 'what good XAML looks like'. Almost everyone I've ever asked this question doesn't have an answer. The couple that did, said, "It should be well formatted."

If formatting is the bar for quality, I think we have a big problem.

And, as people do want more maintainable XAML, we have a big problem.

So, what can we do?

I think consistent formatting is just the start.

Here are some other things to do:

• [Only] include useful, relevant comments.
• Order content within the file so that it matches the order of items being output.
• Structure the use of files within directories in a consistent manner.
• Avoid miscellaneous files that become a "dumping ground" for assorted functionality.
• Follow the Single Responsibility Principle. Give elements in the XAML a single task and, therefore, a single reason to need changing.
• Simplify layout structures within files.
• Avoid using unnecessary elements.
• Avoid setting redundant or duplicate property values.
• Avoid specifying properties with their default values (unless there's a good reason and you add an appropriate comment to explain it to people looking at the code in the future .)
• Don't repeatedly define the same values/items.
• Make use of language features.
• Use inheritance where appropriate.
• Don't use "magic strings"
• Don't use "magic numbers"
• Encapsulated repeated logic.
• Use language features (such as a custom MarkupExtension) to show relationships between values and make those relationships clearer.
• Avoid repetition of text. (So you only need to change it once, in one place.)
• Use semantically meaningful names that show where and when to use something. (Not what it does or looks like.)
• Don't use variations of "Hungarian Notation" when naming UI elements or resources.
• Use inheritance to simplify code. (There are tools that can help with this.)
• Create new types that combine existing ones that are repeatedly used together.
• Create new controls to isolate stand-alone pieces of logic.

There is more detail on the above can be found in the MAUI - Focus on XAML workshop. (Sorry that this means giving you homework, but I'm not sure it's in anyone's benefit to repeat that here.)

Applying the above means that it's easy to go from code like this:

To something much shorter, clearer, and easier to maintain, while still producing the same output (the image in the top right):

Additionally, as there are often multiple ways of achieving the same results, why not use some of those things to reduce the nesting, verbosity, and complexity of XAML with something much shorter and clearer.

For example, why not use an Attached Property to add a gesture recognizer? Like this:

Or something similar for adding behaviours to a control:

Or maybe you want an easier way to specify the values to pick from:

Have a look through the above examples. Take a moment to get past the shock of seeing XAML that isn't as unnecessarily verbose as you're used to.

• Which is easier to read and understand?
• Which is quicker to type?
• Which would you rather maintain?

Why doesn't everyone write code like the above? Each attached property is only a few lines of C#, and yet it makes working with the XAML massively more pleasant.

We're not limited to attached properties.

Creating custom Markup Extensions can greatly reduce the amount of text needed to apply a conversion to a binding and also make the text clearer.

For example, the following shows four versions of a string being displayed. The first is without any conversion and the following three converters applied in different ways.

Plus, creating the extension only required adding an attribute to an existing converter. How simple is that?

Using XML namespaces and carefully choosing names can make code embarrassingly easy to read and understand. Even if you're not familiar with XAML or the code base, is there any confusion about what the following would do?

Or, maybe we use a markup extension to reduce the creation of a complex item with properties (StartPoint, EndPoint, and Offset) that I can't and don't want to have to remember:

XAML doesn't have to be verbose and complex, it comes with ways to use it that are significantly easier to maintain and (relatively) a pleasure to work with.

What is stopping everyone (anyone?) from writing XAML like the simpler versions above? I'm not aware of anything.

In Part 3, I'll show you some tools to create XAML-based applications faster and avoid having to do as much typing.