Jeff Putz mentions a post about a person who switched from an IDE to a text editor and why it isn’t such a good idea. I’m not sure where I stand.
On the one hand, there’s no denying the utility of features like Intellisense and integrated debugger support that he mentions. I would argue that several "text editors" these days support such features, but I will concede that many of them fall short of a really good experience.
On the other hand, I can also agree with many of Charles Petzold‘s points. When you use Visual Studio, it forces you to structure your programs in a specific way. I’ll discuss the hiding of designer code and the lackluster support for WPF file types and why I believe they exemplify a case where an IDE hurts users as opposed to a text editor.
Starting with VS 2005, designer code is hidden away in partial classes. In C#, you are more aware of this because the designer files are displayed along with a separate code file, so it’s clear you’re working on a class spread across several files. In VB .NET, VS pretends like there’s only one file, and since the user can’t see any evidence of designer code one can assume the designer works by magic. One of the main reasons I see cited for this is so the user doesn’t accidentally edit code in a location that’s subject to be modified at the designer’s leisure. There’s really no way to force the designer code into the main class, but it does seem like if you open a file that already has designer code in it, then the designer does the right thing and doesn’t insist you create a partial class.
I care about this because no programmer should ever believe the tools she uses are magic, and forcing the designer code to be hidden enforces this belief, particularly among VB users. I’m very active on a VB .NET programming forum, and I generally see one or two questions a month that either directly ask for information about dynamically creating controls or for which the most elegant solution is dynamically creating controls. More often than not, the poster is completely ignorant of the fact that the VS designer generates code that they could write themselves; sometimes they literally state, "How do I programmatically invoke the designer so I can put some buttons on the form?" Reading through one of Charles Petzold’s books on .NET is a good way to avoid this if you’re a .NET newbie: Petzold tends to start in the code and discourages you from using the designer until you understand what the designer does for you. I wish more beginning programming texts would start this way; the designer-first approach seems to produce programmers that believe there’s a drag-and-drop solution to every problem, and anything without such a solution is not possible.
I don’t argue that there shouldn’t be a designer, but I do argue that the designer code shouldn’t be so well-hidden from the user. I learned how to use several controls by configuring them with the designer, then looking at the code that was generated in VS2003; it’s a shame that many people don’t even know this is possible. What’s interesting is in WPF, you pretty much have no choice but to write code for your layout whether it’s XAML or imperative code, so it seems perhaps this evil practice will fade away.
The next thing I want to discuss is the lackluster support for WPF file types in VS 2008. How do you think I create a loose XAML file in WPF? The use case isn’t necessarily uncommon; suppose I want to create a window and I don’t need a code-behind file, or I want multiple themes for a custom control. I have two choices: I can create a WPF window and delete the code-behind file and edit the XAML file to be what I want, or I can create a new XML file, name it with the XAML extension, and remove the XML document declaration. There’s no way to add just a loose XAML file, even though it’s a fairly common need. I feel like this can lead a new WPF developer to believing silly maxims like, "All Windows must have a XAML and code-behind file".
So while I agree that an IDE can provide utility to a programmer, I also feel that the more code your IDE writes for you or the more templates you use then the more your architecture will be dictated by the tools you use, rather than the needs of your application. I don’t suggest a wholesale switch to text editors, but I do feel like if you can’t use a text editor to write your code then you aren’t familiar enough with your language.
The ResourceDictionary item is another option…but again, not a great one.
What root element are you usually putting in your loose xaml file?
(please reply via email and point me towards this post…so i remember the context.)
Thanks, Rob Relyea
WPF Team
I’d love to respond via email… except your blog link is incorrect and when I did find your blog there’s no contact information.
FYI, in case you see it, the root element in these loose XAML files is typically Window; sometimes I just want a UI playground with no code-behind. In particular, this made following along with Charles Petzold’s WPF book annoying, because the only alternative to VS was XAMLPad or his XAML Cruncher, neither of which has intelligent tabbing, Intellisense, etc.
It’s not necessarily a failure to address a super-common use case, but it is a good example of how the limitations of the tool you use can affect how you approach problems. A user unfamiliar with WPF might draw the conclusion that you cannot have a WPF window with just a code file or just a XAML file.