再见 资源脚本
我非常喜欢.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。
此时，有的只是代码和我本身，有那么一瞬间，我重新找到了一名真正的程序员的感觉。
