1. The designer perspective
UIs are often built by designers using designer tools (expression blend and friends). If I have this kind of worklow, it simply just doesn't work if you put a significant amount of UI-related code in codebehind. At least that's the experience we made. The code and the behavior/functionalty it defines is inacessable to the designer:
- For the most part that code is only
executed at runtime and not while
designing. So the designer doesn't see the full story while designing.
- Designers are not programmers and
only have limited (if at all)
porgramming skills so they most
likely are incapable of refining the
UI behavior defined there.
Additionally we have made the experience that it gets quite hard to find a way to provide mocked designtime data (d:DesignInstance, d:DesignData, d:DataContext
) for the designer to work with if there is codebehind.
2. The developer perspective
UI-related code in codebehind (I am assuming here that it is unnecessary to talk about the odds of putting domain logic in codebehind) is code that is not reusable. It is code that is bound forever to that one specific UserControl/Window/Page. If I for example instead would write a custom attached property or a behavior I get resuablity plus I make our desginers happy because they can use it too.
All code I put in codebehind is code that is hard to test. Of course it mostly doesn't get easier just by putting it in XAML or in a custom attached property. But depending on what type of functionality I put in codebehind there are cases where I could have encapsulate it in testable (reusable) classes.
Defining appearance and behavior in XAML tends to be less (as opposed to the questioners argument) error prone than in code. I just can't make as many mistakes in XAML as I can in code. If I did something wrong chances are that I see it right away in the designer/visual studio. Of course the tools still can improve here. Infact if I additionally use ReSharper those "incorrect spelling" miskates in XAML that the questioner mentions are almost impossible to make. I get that code highlighted right away. I am sure the standard tools will pick this up. XAML is the preferred way to define the UI in WPF and a much higher effort has been made by microsoft to assure that it works as expected than using code. Infact I have already spent quite some time debugging memoryleaks and runtime exceptions on code that did UI related stuff and could have been moved to XAML with little or no extra effort.
If I ease up on the codebehind abstinence there is a higher risk that I write clutterd and bad code. Sometimes it is just to tempting to put a quick hack in codebehind. We have sufferd from the consequences more than once.
Using codebehind is rarely really necessary. Once you get used to ViewModel driven UIs there is alomst never a justifyable necessity for codebehind. It doesn't take much effort to put it somewhere else. So why bother?