For a long time I’ve disliked “designer-generated” code. My preference when writing a Windows Forms (or Swing) app is to work out what it should look like on paper, possibly prototype just the UI in a designer (for the look of it, not the code) and then start with an empty file for real code.

That way, I can end up with a UI which is built up in logical stages (significant UI construction often takes several hundred lines of code – it’s handy to be able to put that in multiple methods with descriptive names, etc), can have code re-use (if all the buttons I create have similar properties, I can write a method to take care of the common stuff), doesn’t put extra fields in for no good reason (how often do labels actually change their text?) and various other things.

I’ve always regarded myself as slightly odd in that respect. However, it seems that Charles Petzold – yes, that Charles Petzold feels the same way and for pretty much the same reasons. Like me, he feels that XAML could help things in terms of autogeneration, as the autogenerated “code” may well look very much like what I’d have written myself, and what’s more, the designer should be able to still understand the XAML after I’ve changed it. Altogether good things.

Anyway, this is all by way of introducing a wonderful article about all of this (and other things): Does Visual Studio Rot The Mind?

In case anyone’s wondering what my take on Intellisense is: the VS.NET 2003 Intellisense seems to get in the way as much as it helps. I expect VS 2005 is better, but I haven’t used it enough to know. Eclipse’s equivalent is much, much nicer than VS.NET 2003, partly because I have a finer degree of control over when it pops up. It’s also brilliant at guessing what parameters I want to pass to methods (really rather surprisingly so at times), and possibly most important of all, it knows how to display more than one overload at a time. VS 2005 beta 2 doesn’t; I’m hoping for a pleasant surprise when the real thing arrives, but we’ll see. To understand what I mean, type Convert.ToString( into Visual Studio. Oh great, I can see 36 overloads – one at a time. Eclipse would give a larger tooltip-style window, with scrollbars. Visual Studio knows how to do that when it’s offering you different method names altogether, but as soon as it comes to overloads, it decides that one-at-a-time is the way to go. Aargh. Anyway, enough ranting…