XAML is not a Turing-Complete language - but treating it like one can be helpful

What is a "Turing Complete language"?

Good question. You can see Wikipedia for more information, but I think of it this way. It's one capable of taking input and producing output based on some form of logical decision-making or processing. 

Basically, it's a clever-sounding name for a general programming language. (Not to be confused with a general-purpose language with no specific focus and distinguished from languages designed explicitly for a particular problem-space or type of usage.)

I think of it as a shorthand for a language you might use when you could (theoretically) use another language and still get the same result.

So, XAML is not "Turing complete" or a "general purpose" language.

It was never meant to be. It was created to represent a user interface (in whole or part) and, to a lesser extent, as a way of describing (or storing) data. [And this data can also be used to store steps in a process or workflow 😉.]

That you can use XAML in combination with a general (or Turing complete) language is irrelevant. That a compiler may take a XAML file and use it to create a C# (or VB.Net, or F#, or anything else) that is used instead of or in partnership with the written XAML doesn't change the XAML file or how you should think about writing it.

Treating XAML like any other "proper" language can be really helpful.

Taking the attitude of "it's only XAML" or "it's just text" doesn't help. It's an attitude that leads to inconsistencies that can make maintaining the code harder and the introduction of actual bugs more likely. It also makes it less likely that you'll look for tools to help write good XAML and ways of writing XAML code that is easy to read and understand. In turn, this will lead to the potential for more accidental bugs and code that is harder for other developers (including future you) to establish the original intention behind the written code.

As XAML files are part of a shipping application, it's essential to treat them the same way you do any development-related asset.

There are many good practices for working with many (most?) programming languages. Not all of these are relevant to working with XAML, but some are.

More posts on this topic will follow...