我最近遇到了这个话题，不明白为什么需要它们。
你能解释一下为什么我应该在我的项目中使用它们以及它们如何让我的生活更轻松。
示例会很棒，我可以从哪里学到更多关于这个主题的知识。
【问题讨论】：
标签： language-agnostic code-generation
如何很好地使用代码生成器的示例？
这使用 t4 模板（Visual Studio 内置的代码生成器）从 .less 文件生成压缩 css： http://haacked.com/archive/2009/12/02/t4-template-for-less-css.aspx
基本上，它允许您在样式表中定义变量、真正的继承，甚至行为，然后在编译时从中创建正常的 css。
【讨论】：
嗯，要么是：
或者：
所以代码生成器为您提供：
优秀的例子：
Linq-to-SQL T4 templates 由 Damien Guard 使用，使用保存最完好的 Visual Studio 2008 机密 - T4 模板，在您的数据库模型中为每个类生成一个单独的文件
PLINQO - 相同，但用于 Codesmith 的生成器
还有无数......
【讨论】：
使用 GUI 构建器为您生成代码是一种常见做法。多亏了这一点，您无需手动创建所有小部件。您只需拖放它们并使用生成的代码。对于简单的小部件，这确实节省了时间（我在 wxWidgets 中经常使用它）。
【讨论】：
只要您需要生成大量重复的样板代码，代码生成器就是您的最佳选择。上次我使用代码生成器是在为项目创建自定义数据访问层时，其中各种 CRUD 操作的骨架是基于对象模型创建的。我没有手动编写所有这些类，而是将模板驱动的代码生成器（使用StringTemplate）放在一起为我制作。该程序的优点是：
【讨论】：
如果使用代码生成器您还打算使用 sn-ps，请尝试在您的类中每次键入 ctor + TAB 和编写构造函数之间的区别。或者检查使用 sn-p 创建与具有许多值的枚举相关的 switch 语句获得了多少时间。
【讨论】：
至少你已经从正确的角度提出了这个问题 =)
使用代码生成器的通常原因是生产力和一致性，因为它们假设解决一致和重复性问题的方法是向其添加更多代码。我认为，任何时候你在考虑代码生成，看看你为什么要生成代码，看看你是否可以通过其他方式解决问题。
一个典型的例子是数据访问；您可以生成 250 个类（架构中的每个表 1 个）有效地创建表网关解决方案，或者您可以构建更像域模型的东西并使用 NHibernate / ActiveRecord / LightSpeed / [pick your orm] 来映射丰富的域模型到数据库中。
虽然手卷解决方案和 ORM 都是有效的代码生成器，但主要区别在于生成代码的时间。对于 ORM，它是在运行时发生的隐式步骤，因此本质上是单向的。手卷解决方案需要在开发过程中生成代码的明确步骤，并且生成的类可能需要在某些时候进行自定义，因此在重新生成代码时会产生问题。开发过程中必须执行的显式步骤会在开发过程中引入摩擦，并经常导致代码违反 DRY（尽管有些人认为生成的代码永远不会违反 DRY）。
吹捧代码生成的另一个原因来自 MDA/MDE 世界（模型驱动架构/工程）。我对此并没有太多关注，但我没有提供一些表达不佳的论点，我只是打算选择其他人 - http://www.infoq.com/articles/8-reasons-why-MDE-fails。
恕我直言，代码生成是极少数问题中唯一的解决方案，每当您考虑它时，您可能应该再看看您正在尝试解决的真正问题，看看是否有更好的解决方案。
真正提高生产力的一种代码生成类型是“微代码生成”，其中使用宏和模板允许开发人员直接在 IDE 中生成新代码，并通过占位符（例如命名空间/类名等）。这种代码生成是 resharper 的一个特性，我每天都大量使用它。在大多数大规模代码生成失败的情况下，微生成受益的原因是生成的代码不会绑定到必须保持同步的任何其他资源，因此一旦生成代码，它就像所有其他代码一样解决办法。
@约翰
将“基本类”的创建从 IDE 转移到 xml / dsl 中经常出现在进行大爆炸式开发时——一个典型的例子是开发人员试图将数据库逆向工程为域模型。除非代码生成器写得很好，否则它只会给开发人员带来额外的负担，因为每次他们需要更新域模型时，他们要么必须进行上下文切换并更新 xml / dsl，要么必须扩展域模型然后将这些更改移植回 xml / dsl（有效地完成了两次工作）。
有一些代码生成器在这个领域工作得很好（LightSpeed 设计器是我能想到的唯一一个 atm），它们充当设计表面的引擎，但通常 这些代码生成器会生成无法维护的糟糕代码（例如 winforms/webforms 设计界面、EF1 设计界面），因此会迅速抵消从使用代码生成器获得的任何生产力优势。
【讨论】：
如果您由 LOC 支付报酬并为不了解什么是代码生成的人工作，那么这很有意义。顺便说一句，这不是玩笑——我曾与不止一个程序员一起使用这种技术来达到这个目的。没有人再正式从 LOC 获得报酬（我知道，无论如何），但程序员通常被期望具有生产力，并且大量编写代码可以让某人看起来有生产力。
作为一个稍微切题的点，我认为这也解释了一些编码人员倾向于将单个逻辑代码单元分解为尽可能多的不同类（曾经继承具有LastName、FirstName 和 @ 的项目） 987654323@ 上课？）。
【讨论】：
真的，当您使用几乎任何编程语言时，您都在使用“代码生成器”（汇编代码或机器代码除外。）我经常编写 200 行的小脚本来生成几千行 C。也是您可以获得的有助于生成某些类型代码的软件（例如，yacc 和 lex 用于生成解析器以创建编程语言。）
这里的关键是将代码生成器的输入视为实际的源代码，并将其输出的内容视为构建过程的一部分。在这种情况下，您使用的是一种高级语言，需要处理的实际代码行数更少。
例如，这是我（没有）在修改基于 Quake2 的游戏引擎 CRX 的工作中编写的一个非常长且乏味的文件。它从两个标头中获取所有#defined 常量的整数值，并将它们转换为“cvars”（游戏内控制台的变量）。
http://meliaserlow.dyndns.tv:8000/alienarena/lua_source/game/cvar_constants.c
这是在编译时生成该代码的简短 Bash 脚本：
http://meliaserlow.dyndns.tv:8000/alienarena/lua_source/autogen/constant_cvars.sh
现在，您更愿意维护哪个？就它们所描述的而言，它们都是等价的，但其中一个要长得多，处理起来也更烦人。
【讨论】：
对于域驱动或多层应用，代码生成是创建初始模型或数据访问层的好方法。它可以在 30 秒内生成 250 个实体类（或者在我的情况下，在 5 分钟内生成 750 个类）。这让程序员可以专注于通过关系、业务规则或 MVC 中的派生视图来增强模型。
这里的关键是当我说 initial 模型时。如果您依靠代码生成来维护代码，那么真正的工作是在模板中完成的。 （正如 Max E 所说。）请注意这一点，因为维护基于模板的代码存在风险和复杂性。
如果您只想“自动创建”数据层以便“在 2 天内使 GUI 工作”，那么我建议您使用面向数据驱动或两个数据驱动的产品/工具集层级应用场景。
最后，记住“garbage in=garbage out”。如果您的整个数据层是同质的并且没有从数据库中抽象出来，请问问自己为什么要费心拥有一个数据层。 （除非你需要看起来富有成效:)）
【讨论】：
实际上，我正在为我被聘用的项目使用的代码生成器添加最后润色。我们有一个巨大的 XML 定义文件，在一天的工作中，我能够生成 500 多个 C# 类。如果我想为所有类添加功能，比如说我想为所有属性添加一个属性。我只是将它添加到我的代码生成中，点击 go，然后 bam！我已经完成了。
真的很好，真的。
【讨论】：
这方面的典型例子是数据访问，但我还有另一个例子。我曾在一个通过串行端口、套接字等进行通信的消息传递系统上工作，但我发现我不得不一遍又一遍地编写这样的类：
public class FooMessage
{
public FooMessage()
{
}
public FooMessage(int bar, string baz, DateTime blah)
{
this.Bar = bar;
this.Baz = baz;
this.Blah = blah;
}
public void Read(BinaryReader reader)
{
this.Bar = reader.ReadInt32();
this.Baz = Encoding.ASCII.GetString(reader.ReadBytes(30));
this.Blah = new DateTime(reader.ReadInt16(), reader.ReadByte(),
reader.ReadByte());
}
public void Write(BinaryWriter writer)
{
writer.Write(this.Bar);
writer.Write(Encoding.ASCII.GetBytes(
this.Baz.PadRight(30).Substring(0, 30)));
writer.Write((Int16)this.Blah.Year);
writer.Write((byte)this.Blah.Month);
writer.Write((byte)this.Blah.Day);
}
public int Bar { get; set; }
public string Baz { get; set; }
public DateTime Blah { get; set; }
}
如果你愿意的话，试着想象一下，为不少于 300 种不同类型的消息编写这段代码。一遍又一遍地编写同样无聊、乏味、容易出错的代码。在我决定只写一个代码生成器对我来说更容易之前，我设法写了其中的 3 个，所以我这样做了。
我不会发布代码生成代码，这是很多神秘的 CodeDom 东西，但最重要的是我能够将整个系统压缩成一个 XML 文件：
<Messages>
<Message ID="12345" Name="Foo">
<ByteField Name="Bar"/>
<TextField Name="Baz" Length="30"/>
<DateTimeField Name="Blah" Precision="Day"/>
</Message>
(More messages)
</Messages>
这容易多少？ （反问。）我终于可以呼吸了。我什至添加了一些花里胡哨的东西，所以它能够生成一个“代理”，我可以编写这样的代码：
var p = new MyMessagingProtocol(...);
SetFooResult result = p.SetFoo(3, "Hello", DateTime.Today);
最后我想说，这节省了我编写 7500 行代码的时间，并将 3 周的任务变成了 3 天的任务（好吧，加上编写代码生成所需的几天）。
结论：代码生成只适用于相对少数的问题，但当你能够使用一个时，它会让你保持理智。
【讨论】：
IsCustom = "True"，它们生成部分类，序列消息使用IsSequence = "True"，因此代码生成器使用可枚举/列表。生成代理不需要更多信息，语法比代码简洁得多，XSD 提供编译时验证（属性映射不可能做到），最重要的是，生成的序列化代码是几个订单比反射更有效，这对于低级协议很重要。
代码生成器在以下情况下很有用：
编写和维护代码生成器的成本低于编写和维护它正在替换的重复的成本。
使用代码生成器获得的一致性将在一定程度上减少错误，使其值得。
调试生成代码的额外问题不会使调试效率低到足以超过 1 和 2 的好处。
【讨论】：
这里每个人都在谈论简单的代码生成，但是模型驱动的代码生成（如 MDSD 或 DSM）呢？这可以帮助您超越简单的 ORM/成员访问器/样板生成器，并为您的问题域生成更高级别概念的代码。
这对于一次性项目来说并不高效，但即使对于这些项目，模型驱动的开发也引入了额外的纪律，更好地理解所采用的解决方案，并且通常是更好的发展路径。
就像 3GL 和 OOP 通过基于更高级别规范生成大量汇编代码来增加抽象一样，模型驱动开发允许我们再次提高抽象级别，同时又提高了生产力。
MetaCase 的 MetaEdit+（成熟）和 Isomeris 的 ABSE（我的项目，处于 alpha 阶段，信息位于 http://www.abse.info）是模型驱动代码生成最前沿的两种技术。
真正需要的是改变思维方式（就像 90 年代需要的 OOP）...
【讨论】：
代码生成有很多用途。
用熟悉的语言编写代码并为不同的目标语言生成代码。
Java -> Javascript
C# -> Objective-C
以更高的抽象级别编写代码。
自动化重复性任务。
忽略所有先入为主的代码生成概念，它基本上是将一种表示（通常是更高级别）转换为另一种（通常是较低级别）。牢记这个定义，它是一个非常强大的工具。
编程语言的当前状态还没有完全发挥其潜力，而且永远也不会。我们将始终进行抽象以达到比我们今天所处的更高的水平。代码生成是我们到达那里的原因。我们可以依赖语言创建者为我们创建抽象，也可以自己做。今天的语言已经足够复杂，任何人都可以轻松做到。
【讨论】：
这里有一些异端：
如果一个任务是如此愚蠢以至于它可以在程序编写时自动化（即源代码可以由脚本生成，比如说 XML），那么同样也可以在运行时完成（即一些表示XML 可以在运行时解释）或使用一些元编程。所以本质上，程序员是懒惰的，没有尝试解决真正的问题，而是采取了简单的方法，编写了一个代码生成器。在 Java/C# 中看反射，在 C++ 中看模板
【讨论】：