Microsoft Mind Rot

Charles Petzold recently gave a very interesting, and rare, talk to a User's Group... and asks whether Visual Studio Rots the Mind:

Visual Studio can be one of the programmer's best friends, but over the years it has become increasingly pushy, domineering, and suffering from unsettling control issues. Should we just surrender to Visual Studio's insistence on writing our code for us? Or is Visual Studio sapping our programming intelligence rather than augmenting it? This talk dissects the code generated by Visual Studio; analyzes the appalling programming practices it perpetuates; rhapsodizes about the joys, frustrations, and satisfactions of unassisted coding; and speculates about the radical changes that Avalon will bring.

I've talked about these sorts of issues at various times, both on this blog, and on my normal blog before I created this one. In my very first month of blogging in fact, I wrote about Why I Hate Wizards. The problem is that not only do Wizards write sometimes bad code, but even if it writes good code, you still need to know what it is! As the developer, and someone who will have to debug that program, you are still responsible for it. Your boss won't accept the excuse of, "Well, the wizard really wrote that code, not me." Personally, I find it very cool that I share so many opinions with Charles Petzold in this regard. I also wonder what Petzold thinks of the new implicit variable feature in C# 3.0?

Petzold also talked about Intellisense quite a bit. My problem with Intellisense is that those who use it a lot, tend to lean on it so much, that it effects everything they do, right down to sloppy variable naming. For me, as a person who prints out code, this is a problem. Unfortunately, Microsoft has yet to develop Intellisense popup tooltips that work on paper. But Petzold brings up a much better point:

For example, for many years programmers have debated whether it's best to code in a top-down manner, where you basically start with the overall structure of the program and then eventually code the more detailed routines at the bottom; or, alternatively, the bottom-up approach, where you start with the low-level functions and then proceed upwards. Some languages, such as classical Pascal, basically impose a bottom-up approach, but other languages do not.

Well, the debate is now over. In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it. If that's not the case, then IntelliSense will try to correct what you're typing by using something that has been defined, and which is probably just plain wrong.

For example, suppose you're typing some code and you decide you need a variable named id, and instead of defining it first, you start typing a statement that begins with id and a space. I always type a space between my variable and the equals sign. Because id is not defined anywhere, IntelliSense will find something that begins with those two letters that is syntactically correct in accordance with the references, namespaces, and context of your code. In my particular case, IntelliSense decided that I really wanted to define a variable of interface type IDataGridColumnStyleEditingNotificationService, an interface I've never had occasion to use.
...
But the implication here is staggering. To get IntelliSense to work right, not only must you code in a bottom-up structure, but within each method or property, you must also write you code linearly from beginning to end - just as if you were using that old DOS line editor, EDLIN. You must define all variables before you use them. No more skipping around in your code.

It's not that IntelliSense is teaching us to program like a machine; it's just that IntelliSense would be much happier if we did.

And I think it's making us dumber. Instead of finding out exactly the method I need, or instead of trying to remember an elusive property name, I find myself scrolling through the possibilities that IntelliSense provides, looking for a familiar name, or at least something that seems like it might do the job.

Because you end up writing your code bottom up instead of top down, you end up doing a much poorer job of architecting it, leading to spaghettified code much earlier in the lifecycle of the program. Until now, I'd never really connected the dots between Intellisense and Spaghetti Code... but I think it's there to see if you look for it.

Anyway, just read the whole thing.