cmaneu / xaml-coding-guidelines

XAML Coding Guidelines
MIT License
37 stars 12 forks source link

Is a guideline for coding XAML really necessary? #7

Open Joebeazelman opened 6 years ago

Joebeazelman commented 6 years ago

I stumbled upon this site while looking for a XAML UI styling guidelines. At first, it makes sense, but after further thought, I wonder if it is necessary. XAML is more like HTML and XML in that it is often generated and is structurally and syntactically simple enough not to become hard to understand.

The main issue with XAML is the large amount of code needed that can be unwieldy to navigate and work with, but its based more on its markup nature, not on how it was written. You guidelines would, however, make an excellent set of rules for formatting XAML in Visual Studio or Resharper. Implementing these guidelines for strictly coded XAML may have limited utility.

haavamoa commented 5 years ago

I feel that having guidelines is extremely helpful at my job. We write XAML and do not generate it, and not following a guideline will result in poorly maintainable code. Large amount can often be solved by breaking it up into smaller files, this helps a lot.

CLIRResearch commented 4 years ago

Haavamoa - I could not agree more. Maintainability is a significant issue with large volumes of XAML. One of the most common complaints is that finding all data sources for a XAML UI frequently involves more than looking at the view-model. A good deal of time is spent locating the data sources. This is especially true when developers who are new to the project are pulled in. Clear (but not excessive) documentation that lists all data sources could save significant time. Why go on code-safari to find something that you should have at your finger tips?

Joebeazelman commented 4 years ago

I guess I'm looking at XAML from a completely different point of view. I see XAML like object code. You would never write it unless your Torvalds (he boasted about hand assembling code), but you may want to inspect it visually during a debugging session. Likewise, XAML should be generated automatically by drawing and connecting UI items. This was done way back in the 1980s. Here we are in 2020 and we can't do better?

WYSIWYG editors have never worked for HTML and almost worked for XAML using Blend, but it doesn't mean we should pull the plug on it. XAML can be made more machinable while still being human readable and editable. Back in the 80s you could create UIs either by editing the .RC files or creating them in a resource editor. HTML and our experiences with XAML have ingrained a distrust for WYSIWYG. Many believe they inherently produce suboptimal code that's inefficient.

WYSIWYG editors can and do excellent code. PostScript is an excellent example. When was the last time you even seen its code? There's a good chance you have use it daily whenever you hit the print button. You didn't care about the code, so long as the print out looks like what you see on the screen. MacOS uses Quartz, a derivative of Display Postscript which essentially did the same thing for the screen.