问你使用代码生成工具吗？

EN

我属于哲学阵营，他们认为代码生成器是“错误的”，因为它们表明了一些应该成为语言一部分的东西。

但写代码是实用主义程序员道德的重要组成部分，实际上，如果生成的代码在默认情况下是隐藏的，那么代码生成就会工作得很好。无论你想要多么纯粹的哲学，语言永远不会像你想要解决的问题那样快速发展。

在Visual Studio中生成Windows窗体时生成的代码就会出现在脑海中。如果愿意，您可以查看生成的代码，但最好不要这样做。但是，使用WPF迁移到声明性语言更好，因为以编程方式操作声明性代码比命令式代码更干净、更可靠。

他们应该对LINQ-To-SQL类做同样的事情。对于只有属性而没有自定义行为的类，他们需要一种声明性语言。这可能更容易使这些实体类成为动态的--当底层数据库模式改变时自动改变。

我们尝试使用CodeSmith为数据库中的所有表生成.NetTiers类，但遇到了两个问题：

1. .NetTiers非常臃肿，并且生成的代码非常庞大。我认为代码生成工具使得创建feep。
2. 变得太容易了，因为模式正在积极地开发和修改，我们也必须重新生成很多东西，这最终使得将所有内容保持在源代码控制中变得非常困难，因为所有的文件都在重新生成和替换。我最终不确定生成的代码是否应该在源代码控制中。

代码生成的最佳位置应该在编译器或构建阶段，而不是设计阶段。在C#中使用匿名类型或方法时，编译器会动态生成代码。如果您在设计阶段生成代码，那么每次底层参数更改时，您都会得到一大块必须重新生成的内容。

不是说我们在.net/web领域工作，而是来自各种自制语言的自制代码生成工具是我们开发工具链中至关重要的一部分。我们有两个主要的这样的工具(带有语法、解析器和形式化定义)，还有一大堆次要的工具，它们是基于宏构建的，比如m4和perl。它们最终都会生成原生编译的纯C语言。

根据我的经验，特定于领域的语言是程序员在任何大规模软件工作中提高工作效率的关键工具之一。如果您正在构建编译器、模拟器或其他具有许多在basic语言中根本不支持的循环模式的非常复杂的软件(这通常意味着可移植的C，有时是C++)，则代码生成工具是可行的。我认为特定于域的语言是泛化的下一步:首先将常见的计算分解为函数(或历史上的子例程)，然后将常见的函数分解为模板或泛型(如果有这样的工具可用)，然后将更多的通用性和重复代码分解为成熟的自定义语言。

这一切都是为了减少您实际编写的代码量，并从编程过程中删除任何形式的乏味重复和无价值的代码。一旦模式重复，就应用一种特定领域的语言！

当我做经典的asp工作时(大约在2001年)，我开始使用自己的生成器(数据访问、sprocs等)。我慢慢地转向了CodeSmith，因为它更容易处理。我仍然主要是为我的.NET代码生成所有数据访问层类型的东西(包括sprocs)。

几年前，我从宏代码生成(即CodeSmith)跳到了微代码生成。

不同的是，使用CodeSmith，我为我的应用程序生成了大量的代码，这些代码都是通用的，而且是一次性生成的。当改变模板的源(即表结构)时，这对于边缘情况和重新生成变得有问题。我还遇到了这样的情况，即有大量我不使用的代码，但这些代码是从我的模板中生成的。所有这些方法都有效吗？可能会，也可能不会。进入并清理生成的代码将是一项巨大的工作(即在同一代码库上花费了一年多的时间)。

相比之下，微代码生成允许我在我想要的正确场景中生成我需要的类。我用来做这件事的主要工具是ReSharper。我这样做的方法是先编写单元测试，然后再编写生产代码。在该场景中，ReSharper使用我的单元测试作为模板，为生产代码自动生成框架。然后，这只是一个填补空白的问题。

对于数据访问，我不再生成任何内容。我发现一个好的O/R取代了我过去放在我的数据访问层中的所有东西(即NHibernate)。鉴于此，在我的生活中，我再也不会编写或生成另一个数据访问层(我拒绝这样做)。

此外，我还获得了拥有大型单元测试套件以及其他功能的好处。