本文是Charles Petzold于2005年10月20日在NYC.NET开发者小组中的演讲稿节选。Visual Studio或许是程序员最好的伴侣之一，但这些年来，它变得日益冒进、专制，控件问题也变得越来越混乱。难道我们应该投降，让Visual Studio替我们来编写代码吗？还是它正在侵蚀我们的编程聪明而不是使我们增长聪明？这篇演讲剖析了Visual Studio生成的代码，分析了它为我们造就的令人震动的编程习惯；狂热地表达了独立编程过程中的喜悦、挫折和满足感。
技术成瘾，信息尽在指尖的麻烦
在使用计算机时，键盘和鼠标或许会使我们患上重复性神经压迫障碍症（repetitive stress disorder），.. 但软件对思想的影响要远远大于身体，即便如此，这种影响也是不易察觉的。
有些观察家在观察我们的数字化生存方式后，注重到某些应用程序使用户以一种非常严格的预先设计好的方式进行思考，而且我们总是这样谈论一种消费技术：“在拥有它之前，我们根本不知道有多么需要它。”而大多数此类技术似乎都不是为了满足某种特定的需求，只是使我们沉迷于原本从未需要过的其他东西；不是为了使我们生活得更好，只是引诱我们服下设计师提供的又一剂迷药。一旦我们尝到甜头，就被引诱了。
20 世纪90年代初，Microsoft公司提出了一个口号“信息尽在您指尖。”理论上来讲，这听起来相当不错，而今天，有了Google、Wikipedia、Internet MovieDatabase和其他有用的网站，这个梦想基本上已经实现。
没有Visual Studio（以下简称为VS），世界将会怎样？它使我们按照各种预先设计好的方式进行工作，举例来说，假如VS实现的功能比现在少，那么人们是否会更兴奋？VS的某些特性大大提高生产力，但就我个人而言，它们看上去贬低了VS，也减少了我的编程经验。
自从20年前的1985年11月，Windows 1.0初次登场，记录的函数调用约有400种。10年以后，Windows 95中的函数调用超过了1000种。今天我们已经作好了迎接.NETFramework 2.0正式版的预备。仅仅统计MSCORLIB.DLL和那些以System开头的程序集，就有超过5000种公共类，包含超过45000 种公共方法和15000种公共属性，这还没有计算那些派生而来以及未重写的方法和属性。有这样一位能把握60000种方法和属性的程序员吗？我认为没有。解决方案之一当然就是专门化。
IntelliSense
VS试图通过IntelliSense这种特性降低类、方法和属性的大规模扩展给人们带来的问题。在防止用户出格方面，假如您将“指尖”理解为对屏幕上插入键所在位置的比喻，那么IntelliSense实际上就实现了“信息尽在指尖”这一目标。它与.NET配合得天衣无缝，这是因为VS可以使用映射从您指定为引用的实际DLL中获取所需的全部信息。
为使IntelliSense正常运作，自下而上的编程是最佳选择。IntelliSense要求每一个类、每一个方法、每一个属性等等都必须得到正确的定义，然后才能引用。假如您没有这样做，IntelliSense将使用已定义的相应内容尝试纠正您键入的代码，这可能会导致出错。
但这里的结论令人惊愕。要想使IntelliSense正常运作，不仅要求使用自下而上的结构编程，在每一个方法或属性中，您还必须要从开始到结束呈线性地编写代码——这简直就像使用古老的DOS行编辑器EDLIN。您必须首先定义所有的变量，然后才能使用它们。根本不能在代码中越行编写。
我不需要再记住任何东西。IntelliSense会帮我记住。我的编程过程成了一场与IntelliSense的持久对话。因此我不认为IntelliSense能帮助我们成为更出色的程序员。它实际的目标是使我们成为效率更高的程序员，这也就意味着使我们的劳动更为廉价。
IntelliSense是一种不可避免要出现的技术。即便Microsoft公司没有开发出它，其他人也会将它带给我们。人类从不因为可能出现不幸的结果而尽量避免追捧某些技术。
生成的代码
VS不仅仅试图完成我们正在键入的代码，多年以来，它一直想要为我们生成代码。例如，假如选择WindowsApplication作为新项目类型，给它命名并指定本机驱动器上的存储位置后，VS就会生成足够的代码，以使这一项目立即可编译、可运行。
出于某种原因，我们都已经相信了这是编程的合理方式。我更喜欢自己键入预备代码，然后自己输入main函数或Main方法。我真正需要帮助的时机绝对不是开始编程时，而是在我试图结束编程时。那个时候VS又在干什么？
VS会将我们编写的程序与一组它认为我们需要的动态链接库挂钩，而不管您的程序是否真的需要这些DLL。这些额外的引用不会造成任何实际的损害，但假如其他人查看程序，会造成一些混乱。
在其他文件中，VS会创建一个名为Form1.cs的文件，这是源代码文件，事件处理程序将其应用于主窗体中的控件。您会在代码顶端看到一组命令，包含了程序需要的命名空间。除了WindowsForm程序标准命名空间外VS还包含了很多自创的东西，其中某些的确非常有用，但假如程序并未实际使用这些命名空间中的任何类，那它们就只不过是令人分心的噪声。
VS还在一个以项目名称命名的命名空间内封装了其生成的所有代码。当然，我完全理解给DLL一个命名空间的价值，但是为什么要给应用程序一个命名空间呢？我就这个问题考虑了很久，但没有得到答案。
VS还会创建一个名为Form1.Designer.cs的文件，在VS 2005的某些测试版中，这个文件甚至不会默认地显示在项目文件中。这是VS在您设计窗体时插入生成代码的文件。VS显然不希望您搞乱这个文件，出于某些很好的理由，VS希望这些生成的代码采用一种特定的格式，假如您把它搞乱了，那么VS就无法在您再次打开项目时读回这些代码。
更多的请看：http://www.QQread.com/windows/2003/index.Html交互式设计
绝大多数革命性的交互式设计素材都是在Visual Basic基于Windows的版本中写下第一个表达式的，也正是从这里开始，我陷入了对Windows编程发展方向的深深忧虑。您不仅可以将按钮移动到窗体中、以交互式方式将其位置和大小调整为所需结果，而且假如您单击按钮，Visual Basic还会生成一个事件处理程序并答应您在其中键入代码。
Visual Basic不是将程序作为一个完整连贯的文档来处理，而是作为附属于可视化对象的代码段来处理的，这是我困扰的原因所在。这 不是程序应该有的样子。这不是编译器看到的东西。之后人们要怎样才能获得一种对完整程序的感觉呢？这令我感到非常困惑。
交互式设计素材最终在C++开发和Microsoft Foundation Class中找到了自己的位置，代码生成的背后实际隐藏的东西根本没人愿意探讨，那就是多到令人毛骨悚然的MFC支持，我对此深信不疑。我不断地推出《Windows程序设计》的修订版，我认为其读者群是像我一样喜欢从头开始编写自己的代码的程序员。
再见！资源脚本
我非常喜欢.NET 1.0测试版及Windows Form，其面向对象的程度显然要比MFC高得多，同时也非常好奇资源脚本就这样彻底消失了。用户在代码的对话框中——现在包容于一个更为通用的术语“窗体”中——创建并组合控件。当然，即便是在Windows 1.0中，您也可以通过代码创建控件，但那种体验不是非常令人愉快，因为创建每个控件时都要调用带有11个参数的CreateWindow函数。在Windows Form中通过编写代码创建控件是非常方便的。
例如VS并不希望您使用数组或循环来创建并定位一组按钮，它希望您使用设计器，它希望为您生成代码，并将这些代码藏在您看不见的地方。
在第一个对话框编辑器面世约20年以后的今天，VS又犯下了生成不美观的代码还警告您不要搞乱它的错误。当然，我们知道VS这样做的原因。理论上来讲，您可以为VS的工具箱增加另外一个名为Button的空间——从另一个命名空间的另一个DLL，所以必须有区分它们的方法。
VS是根据您所选择的控件生成代码的，它为控件赋予标准名称并答应您更改变量名称，只要更改控件的属性即可，那么不仅按钮对象的属性会改变，按钮变量名也会随之更改。VS所做的一切都只是为了使您更快地写出代码。
程序员真的会以这样的方式设计代码吗？我可以确定地说，确实有一些这样的人，但同样可以确定大部分程序员都不会这样做。
在探讨关于变量名的话题时，我应该说一些VS的优点。VS 2005有一种极为出色的变量重命名工具。大家都知道，有时真的需要重新命名一个变量，但还要依次更改其在程序中实际使用的地方，而查找并替换显然有带来负面效应的可能，您碰到这种情况有几次？现在，这一全新的变量重命名工具使您避免了所有的麻烦，而且，假如您将其命名为与现有名称重复，这一工具还会给您以提示。我希望人们能充分利用这一工具来重命名他们的控件，不要保留VS的默认设置。
过度使用的字段
VS自动生成代码带来的另外一个问题就是每个控件都是创建该控件的类中的一个字段。这是一种可怕的编程经历，程序员也许会通过观察VS生成的代码来学习正确的编程技术，但他们所看到的就是这个。
面向对象编程技术出现后，全局变量在其中起的作用已经微乎其微，只有那些字段现成为的全局变量，且其滥用情况非常严重。
理论上来说，做为窗体一部分创建的任何子控件都不需要作为字段存储，因为其父——通常为窗体，您可以使用为属性索引的整型值或在创建控件时为属性指派的文本引用各控件。此时假如您的控件有着有意义的名称，而不是button1和button2，那么您会再次发现其优势。
作为程序员，我们应该就每一个特定对象进行谨慎的思考，它是定义为字段还是局部变量。假如一个标签在整个窗体存在期间都有着同样的文本，那么可以很轻易地判定出，它应该定义为局部变量。而假如一个标签的文本是通过事件处理程序或其他某些控件设置的，则或许将其存储为字段是最方便的。
事情就是这么简单，但VS不希望您这么想。VS希望将所有东西都存储为字段。
揭开VS的神秘面纱
即使VS可生成完美的代码，依然有一个问题。由于VS可生成代码，它在代码和程序员之间耸立起一道无形的墙壁。VS向我们暗示这是编写现代Windows或Web程序的惟一途径，因为现代程序设计的某些方面只有VS知道其来龙去脉。VS还提供了样板代码，其中包含一些从未在Microsoft公司提供的文档或指南中充分论述过的材料，这进一步增加了VS的权威感。
这给我带来了一种被强制的感觉,作为一名Windows Form编程和Avalon编程教师,我故意与其背道而驰。我觉得我需要揭开VS的神秘面纱,让人们看看它到底在做什么,并且示范如何自行编写代码开发这些应用程序,假如您愿意,我们甚至可以离开VS,在命令行中编译这些代码。
纯粹的编写代码带来的纯粹快乐
几个月之前，或许是为了反抗所有这些高傲的Windows Form和Avalon编程技术，我开始重新使用C语言编写程序。编写的代码并不多。
通过一些实际的项目，我发现我不必查找任何资料，我用C语言编程的经验有20年。在C#出现之前，这是我最喜爱的语言。这项任务是纯粹地编写算法，然后输出简单的结果。这就是全部内容。
我还发现在编写代码之前，确实需要好好动动脑筋。采用全部可能的组合总是不答应的。您需要削减一部分。经过这样的初步处理后，还有实际的代码要去编写，但这里没有API、没有类、没有属性、没有窗体、没有控件、没有事件处理程序，当然也根本没有VS。
此时，有的只是代码和我本身，有那么一瞬间，我重新找到了一名真正的程序员的感觉。
