如果可以生成某些东西，那么那是数据，而不是代码。

鉴于此，对源代码生成的整个想法不是一种误解吗？也就是说，如果有某个东西的代码生成器，那么为什么不将该东西变成一个可以接收所需参数并执行“将要生成的”代码将要执行的正确操作的适当函数呢？

如果这样做是出于性能原因，那么这听起来像是编译器的缺点。

如果要完成两种语言之间的桥梁，那么这听起来像缺少接口库。

我在这里想念什么吗？

我知道代码也是数据。我不明白的是，为什么要生成源代码？为什么不使其成为可以接受参数并对其执行操作的函数呢？

源代码生成是反模式吗？

从技术上讲，如果我们生成代码，即使它是人类可以阅读的文本，它也不是源代码。 源代码是由人类或其他真正的智慧生成的原始代码，未经机械翻译且不能从（真实）源（直接或间接）立即复制。

如果可以生成某种东西，那么那是数据，而不是代码。

我会说一切都是数据。甚至源代码。 特别是源代码！ 源代码仅仅是一种旨在完成编程任务的语言中的数据。该数据将根据需要转换，解释，编译，生成为其他形式的数据，其中某些形式恰好是可执行的。

处理器执行内存不足的指令。用于数据的相同内存。在处理器执行指令之前，程序将作为数据加载到内存中。

因此，一切都是数据，甚至是代码。

鉴于[生成的代码就是数据]，整个代码生成的想法难道不是一个误解吗？

最好有多个编译步骤，其中一个步骤可以是将中间代码生成为文本。

也就是说，如果有某个东西的代码生成器，那么为什么不将该东西变成一个可以接收所需参数并执行“将要生成的”代码将要执行的正确操作的适当函数呢？

那是一种方法，但是还有其他方法。

代码生成的输出是文本，这是设计供人类使用的东西。

并非所有文本形式都供人食用。特别是，生成的代码（作为文本）通常旨在供编译器使用而不是人类使用。

源代码被认为是原始代码：大师-我们编辑和开发的内容；我们使用源代码控制归档的内容。即使是人类可读的文本，生成的代码通常也会从原始源代码中重新生成。一般来说，生成的代码不必受源代码控制，因为它是在构建过程中重新生成的。

实用推理

好的，我知道代码也是数据。我不明白的是，为什么要生成源代码？

通过此编辑，我假设您是在相当实际的水平上提出问题，而不是理论上的计算机科学。

用Java之类的静态语言生成源代码的经典原因是，此类语言实际上并没有真正易于使用的语言工具来完成非常动态的工作。例如，在Java的形成时代，根本无法轻松地创建一个具有动态名称（与数据库中的表名匹配）和具有动态数据类型（与数据库中的表名匹配）的动态方法（与该表中的属性匹配）的类。所述属性的类型）。特别是由于Java在编译时能够捕获类型错误时非常重视，不保证。

因此，在这种情况下，程序员只能创建Java代码并手动编写很多行代码。通常，程序员会发现，每当表发生更改时，他都必须返回并更改代码以使其匹配。如果他忘记了那件事，就会发生坏事。因此，程序员将到达编写自己的工具的地步。因此，这条路开始了越来越智能的代码生成。

（是的，您可以动态生成字节码，但是用Java编程这样的事情并不是随机程序员在编写几行域代码之间所做的事情。）

将此与动态性很强的语言（例如Ruby）进行比较，我会在大多数方面考虑Java的对立面（请注意，我在说这时并不重视任何一种方法；它们只是有所不同）。在这里，在运行时动态生成类，方法等是100％正常和标准的，最重要的是，程序员可以在代码中轻松完成它，而无需进入“元”级别。是的，诸如Ruby on Rails之类的东西是随代码生成一起提供的，但是我们在工作中发现，基本上，我们将它用作新程序员的一种高级“教程模式”，但是过了一会儿它就变得多余了（因为代码太少了）在该生态系统中编写代码，当您知道自己在做什么时，手动编写它比清理生成的代码要快。

这些只是来自“现实世界”的两个实际示例。然后，您就有了像LISP这样的语言，其中的代码实际上就是数据。另一方面，在编译语言中（没有像Java或Ruby这样的运行时引擎），（或者曾经，我没有跟上现代C ++功能...）根本没有在运行时定义类或方法名称的概念，因此，代码生成构建过程是大多数事情的首选工具（其他更多C / C ++特定示例是诸如flex，yacc等之类）。

为什么生成代码？

因为使用打孔卡（或记事本中的alt代码）进行编程很麻烦。

如果这样做是出于性能原因，那么这听起来像是编译器的缺点。

真正。除非被迫，否则我不关心性能。

如果要完成两种语言之间的桥梁，那么这听起来像缺少接口库。

嗯，不知道你在说什么。

看起来像这样：生成并保留的源代码永远是永远的难题。它存在仅出于一个原因。有人想用一种语言工作，而其他人则坚持用另一种语言工作，任何人都不会费心找出如何在它们之间进行互操作，因此其中一个人想出了如何将自己喜欢的语言变成所强加的语言，以便他们可以做什么他们要。

在我必须维护它之前，这很好。在这一点上，你们都可以死。

是反模式吗？igh，不。如果我们不愿意告别以前的语言的缺点，那么许多语言甚至都不存在，而生成旧语言的代码就是多少种新语言的开始。

这是我忍受不了的一半转换科学怪人拼凑而成的代码库。生成的代码是不可修改的代码。我讨厌看无法触及的代码。但是人们一直在检查它。为什么？您可能还需要检入可执行文件。

好吧，我正在咆哮。我的观点是，我们都是“生成代码”。当您将生成的代码像源代码一样对待时，会让我发疯。只是因为看起来像源代码并没有使其成为源代码。

为什么生成源代码

我在职业生涯中最常使用的代码生成器用例是生成器

• 将某种数据模型或数据库模式作为输入（可能是关系模式或某种XML模式）进行了高级元描述。

• 并生成了用于数据访问类的样板CRUD代码作为输出，并且可能还有其他内容，例如相应的SQL或文档。

这样做的好处是，从简短输入规范的一行开始，您将获得5到10行可调试，类型安全，无错误的代码（假定代码生成器的输出已经成熟），否则您必须手动实现和维护这些代码。您可以想象这将在多大程度上减少维护和开发工作量。

让我也回答您的最初问题

源代码生成是反模式吗

不，本身不是源代码生成，但是确实存在一些陷阱。如The Pragmatic Programmer中所述，在生成难以理解的代码时，应避免使用代码生成器。否则，增加的使用或调试此代码的工作量可能很容易超过不手动编写代码而节省的工作量。

我还想补充一点，通常是一个好主意，即以物理方式从手动编写的代码中分离出代码的生成部分，以便重新生成不会覆盖任何手动更改。但是，我也已经不止一次地处理过这种情况，即任务是将用旧语言X编写的一些代码迁移到另一种更现代的语言Y上，并打算随后使用语言Y进行维护。这是有效的用法一次性代码生成的情况。

为什么要生成源代码？

我遇到了两个生成（在构建时，从未签入）代码的用例：

1. 通过用于指定特定内容的语言自动生成样板代码，例如getter / setter，toString，equals和hashCode。
2. 根据某些接口规范（REST，SOAP等）自动生成DTO类型类，然后在主代码中使用。这类似于您的语言桥梁问题，但是最终变得更简洁，更简单，并且与尝试在没有生成类的情况下实现相同的事物相比，类型处理更好。

Sussmann在他的经典著作《计算机程序的结构和解释》中对这些事情有很多有趣的说法，主要是关于代码数据二元性的。

对我来说，即席代码生成的主要用途是利用可用的编译器将一些特定于领域的语言转换为可以链接到程序中的语言。想想BNF，想想ASN1（实际上，不要，这很丑陋），想想数据字典电子表格。

琐碎的领域特定语言可以节省大量时间，并且在创建这样的东西时，输出通过标准语言工具可以编译的东西是一种方法，而您宁愿编辑这种琐碎的手动分析器，无论您使用哪种母语写作，还是自动生成的BNF？

通过输出文本，然后将其输入到某些系统编译器，我无需进行任何考虑即可获得所有这些编译器的优化和特定于系统的配置。

我正在有效地将编译器输入语言用作另一种中间表示形式，这是什么问题？文本文件不是天生的源代码，它们可以是编译器的IR，并且如果它们恰好看起来像C或C ++或Java或其他内容，谁在乎？

现在，如果您很难想到可以编辑玩具语言解析器的输出，那么下次有人编辑输入语言文件并进行重建时，这显然会让您失望的，答案是不要将自动生成的IR提交给存储库由您的工具链生成的（并且避免在您的开发团队中拥有这样的人，他们通常在市场营销方面会更快乐）。

这并不是我们语言表达能力的失败，它表达了以下事实：有时您可以将规范的某些部分（或按摩）成一种可以自动转换为代码的形式，并且通常会少得多错误，并且易于维护。如果我可以给我们的测试和配置人员一个电子表格，他们可以对其进行调整，然后他们运行一个工具来获取数据，并在ECU上为闪存生成一个完整的十六进制文件，那么与由他人手动翻译相比，这将节省大量时间将最新的设置转换成一天中用语言表示的一组常量（用错别字完成）。

在Simulink中构建模型，然后用RTW生成C，然后使用任何有意义的工具进行编译，以达到目标，中间C是不可读的，那又如何呢？高级Matlab RTW东西只需要知道C的子集，C编译器负责平台的细节。只有当RTW脚本有bug时，人类才需要仔细检查生成的C，这种事情用名义上可读的IR进行调试比使用二进制分析树要容易得多。

您当然可以编写这样的东西来输出字节码甚至可执行代码，但是为什么要这样做呢？我们有将IR转换为这些东西的工具。

务实的答案：代码生成是否必要且有用？它是否提供了真正非常有用的专有代码库所需要的东西，或者它似乎只是创造了另一种处理方式，从而为次优结果贡献了更多的智力开销？

好的，我知道代码也是数据。我不明白的是，为什么要生成代码？为什么不使其成为可以接受参数并对其执行操作的函数呢？

如果您必须提出这个问题，但没有明确的答案，那么代码生成可能是多余的，并且只会给代码库带来异国情调和大量的知识开销。

同时，如果您采用类似OpenShadingLanguage的方法：https : //github.com/imageworks/OpenShadingLanguage

……然后，无需提出此类问题，因为令人印象深刻的结果将立即回答这些问题。

OSL使用LLVM编译器框架将着色器网络即时转换为机器代码（及时或“ JIT”），并且在此过程中充分了解了着色器参数和其他运行时值，从而极大地优化了着色器和网络。从源代码编译着色器时已经知道。结果，我们看到我们的OSL着色网络的执行速度比用C手工制作的等效着色器快25％！（这就是我们的旧着色器在渲染器中的工作方式。）

在这种情况下，您无需质疑代码生成器的存在。如果您在这种VFX域中工作，那么您的直接反应通常是，“闭嘴，拿走我的钱！” 或者，“哇，我们还需要做这样的事情。”

不，生成中间代码不是反模式。您的问题另一部分“为什么要这么做”的答案是一个非常广泛（和单独）的问题，尽管无论如何我都会给出一些原因。

从来没有中间可读代码的历史后果

让我们以C和C ++为例，因为它们是最著名的语言之一。

您应该注意，编译C代码的逻辑过程不是输出机器代码，而是输出人类可读的汇编代码。同样，旧的C ++编译器通常将C ++代码物理地编译为C代码。在那一系列事件中，您可以从人类可读代码1到人类可读代码2到人类可读代码3到机器代码进行编译。“为什么？” 为什么不？

如果从未生成中间的，人类可读的代码，那么我们甚至可能根本没有 C或C ++。这肯定是有可能的。人们走的道路对他们的目标的抵抗最小，如果其他一些语言由于C发展停滞而首先获得发展，那么C可能在它还很年轻的时候就死了。当然，您可以争论“但是也许我们会使用其他语言，也许会更好。” 也许，也许会更糟。也许我们都还是在汇编中。

为什么要使用人类可读的中间代码？

1. 有时需要中间代码，以便您可以在下一步构建之前对其进行修改。我承认这一点是最薄弱的。
2. 有时是因为原始工作根本不是用任何人类可读的语言完成的，而是在GUI建模工具中完成的。
3. 有时您需要做一些非常重复的事情，而该语言不应该满足您的工作，因为它是一件小众事物或一件如此复杂的事情，以至于它无济于事，只会增加编程语言的复杂性或语法您。
4. 有时，您需要做一些非常重复的事情，而无法以一种通用的方式将您想要的东西转化为语言。它不能由语言的语法表示或与语言的语法冲突。
5. 计算机的目标之一是减少人工工作，有时不可能再次触及的代码（维护的可能性很小）可以编写元代码以十分之一的时间生成更长的代码。如果我可以在1天而不是2个星期内完成它，并且不太可能再维护一次，那么我最好生成它-并且从5年后的某个时候开始就烦恼某个人，因为他们实际上确实需要维护它，然后他们可以花2周完全写出来，如果他们想，或1周惹恼保持尴尬的代码（但我们仍为1提前一周在这一点），这就是如果保养需以全部完成。
6. 我敢肯定，还有其他原因我会忽略。

例

我曾参与过一些项目，这些项目之前需要根据其他文档中的数据或信息生成代码。例如，一个项目的所有网络消息和常量数据都在电子表格中定义，并且该工具可以遍历电子表格并生成大量的C ++和Java代码，使我们可以处理这些消息。

我并不是说这是建立该项目的最佳方法（我不是启动项目的一部分），但这就是我们所拥有的，它是数百个（甚至可能是数千个，不确定）结构，对象和常量产生的；到那时，尝试以Rhapsody之类的方式重做可能为时已晚。但是即使重做了Rhapsody之类的东西，无论如何我们仍然有从Rhapsody生成的代码。

同样，将所有数据包含在电子表格中也是一种不错的方式：它使我们能够以原始数据文件中没有的方式来表示数据。

例子2

在进行编译器构造工作时，我使用了Antlr工具进行词法分析。我指定了一种语言语法，然后使用该工具在C ++或Java中吐出了大量代码，然后将生成的代码与自己的代码一起使用，并将其包含在构建中。

那应该怎么做呢？也许您可以想出另一种方法；可能还有其他方法。但是对于这项工作，其他方式不会比我生成的lex / parse代码更好。

您缺少的是重用。

我们有一个了不起的工具，可以将源代码文本转换为二进制文件，称为编译器。它的输入定义明确（通常是！），并且它已经通过大量工作来完善其优化方式。如果您实际上要使用编译器执行某些操作，则要使用现有的编译器而不是自己编写。

许多人确实发明了新的编程语言并编写了自己的编译器。几乎没有例外，他们之所以这样做，是因为他们乐于接受挑战，而不是因为他们需要该语言提供的功能。他们所做的一切都可以用另一种语言完成；他们只是在创造一种新的语言，因为他们喜欢这些功能。但是，经过优化的，快速，高效，优化的编译器并不能使它们获得成功。可以肯定的是，它将为他们提供一些可以将文本转换为二进制的东西，但是它不如所有现有的编译器好。

文本不仅仅是人类阅读和书写的东西。电脑也很适合在家中放置文字。实际上，像XML这样的格式（以及其他相关格式）是成功的，因为它们使用纯文本。二进制文件格式通常晦涩难懂，文档记录不清，读者无法轻易找到它们的工作方式。XML是相对自文档的，因此人们可以更轻松地编写使用XML格式文件的代码。并且所有编程语言均已设置为读取和写入文本文件。

因此，假设您想添加一些新的设施来简化您的生活。也许这是一个GUI布局工具。也许是Qt提供的信号和插槽接口。TI的Code Composer Studio也许就是这种方式，它使您可以配置正在使用的设备并将正确的库放入构建中。也许是要使用数据字典并自动生成typedef和全局变量定义（是的，这在嵌入式软件中还是很重要的）。不管是什么，利用现有编译器的最有效方法是创建一个工具，该工具将接受您所需要的配置并自动以您选择的语言生成代码。

它很容易开发和测试，因为您知道发生了什么，并且可以阅读它吐出的源代码。您不需要花很多年的时间来构建与GCC竞争的编译器。您不需要学习全新的语言，也不需要其他人来学习。您需要做的就是自动化这一小区域，其他一切保持不变。任务完成。

答案比较实用一些，集中在为什么而不是什么源代码上。请注意，在所有这些情况下，生成源代码都是构建过程的一部分-因此，生成的文件不应进入源代码控制。

互操作性/简单性

以Google的协议缓冲区为例：您编写了一个高级协议描述，然后可以用它来生成多种语言的实现-通常，系统的不同部分用不同的语言编写。

实施/技术原因

使用TypeScript-浏览器无法解释它，因此构建过程使用翻译器（代码到代码翻译器）生成JavaScript。实际上，许多新的或深奥的编译语言都是在获得合适的编译器之前先将其编译为C。

使用方便

对于用C编写且仅使用单个二进制文件（RTOS或不使用OS）的嵌入式项目（例如IoT），很容易生成一个C数组，将要编译的数据就像普通的源代码一样，直接链接到它们作为资源。

编辑

扩展protobuf：代码生成使所生成的对象成为任何语言的一流类。在编译语言中，通用解析器必须返回键值结构-这意味着您需要大量样板代码，错过了一些编译时检查（尤其是键和值类型），导致性能下降，没有代码完成。想象一下用C语言编写的所有内容void*，或者std::variant用C ++语言编写的大量内容（如果您有C ++ 17），某些语言可能根本没有这种功能。

源代码生成是反模式吗？

对于表达能力不足的编程语言，这是一种变通方法。无需使用包含适当的内置元编程的语言来生成代码。

源代码生成并不总是一种反模式。例如，我目前正在编写一个框架，该框架根据给定的规范以两种不同的语言（Javascript和Java）生成代码。框架使用生成的Javascript记录用户的浏览器操作，并在框架处于重播模式时使用Selenium中的Java代码实际执行操作。如果不使用代码生成，则必须手动确保两者始终保持同步，这既麻烦又以某种方式进行逻辑复制。

但是，如果有人使用源代码生成来替换通用特性（如泛型），那么它就是反模式。

我在这里想念什么吗？

也许中间代码成为成功的一个很好的例子？我可以为您提供HTML。

我认为，对于HTML来说，简单和静态非常重要-它使浏览器的制造变得容易，允许早期启动移动浏览器等。随着进一步的实验（Java Applet，Flash）表明-更复杂，更强大的语言会导致更多问题。事实证明，用户实际上受到Java小程序的威胁，而访问此类网站就像尝试通过DC ++下载的游戏破解程序一样安全。另一方面，纯HTML足够无害，因此我们可以在合理相信设备安全性的情况下检出任何站点。

但是，如果不是由计算机生成的，HTML将远不及现在。在有人手动将其从数据库重写为HTML文件之前，我的答案甚至不会显示在此页面上。幸运的是，您可以使用几乎任何编程语言制作可用的HTML :)

也就是说，如果有某个东西的代码生成器，那么为什么不将该东西变成一个可以接收所需参数并执行“将要生成的”代码将要执行的正确操作的适当函数呢？

您能想象比将HTML用作生成的中间代码更好的方式向用户显示问题以及所有答案和注释吗？

为什么要生成源代码？

因为它比手动编写代码更快，更容易（并且更不容易出错），特别是对于繁琐而重复的任务。在编写一行代码之前，您还可以使用高级工具来验证和验证您的设计。

常见用例：

• 诸如Rose或Visual Paradigm的建模工具；
• 高呃水平的语言，如嵌入式SQL或必须预处理到的东西编译接口定义语言;
• lexer和解析器生成器，例如flex / bison；

至于“为什么不仅仅使它成为一个函数并将参数直接传递给它”，请注意，以上都不是其自身的执行环境。无法将代码与它们链接。

有时，您的编程语言只是没有所需的功能，实际上使编写函数或宏来执行所需的操作实际上是不可能的。也许您可以做您想做的事，但是编写它的代码却很难看。然后，一个简单的Python脚本（或类似脚本）可以在构建过程中生成所需的代码，然后#include将其生成实际的源文件。

我怎么知道 因为这是我在使用各种不同的系统（最近是SourcePawn）时多次接触到的解决方案。当最终得到两打这样的代码行（创建我的所有cvar）时，一个简单的Python脚本可以解析一条简单的源代码并生成两到三行已生成的代码，这比手动制作已生成的代码要好得多。

演示/示例源代码，如果人们需要的话。

需要文本形式以便于人类容易使用。计算机也很容易以文本形式处理代码。因此，生成的代码应以最容易生成和最容易被计算机使用的形式生成，并且通常是可读文本。

而且，当您生成代码时，代码生成过程本身通常需要进行人工调试。如果生成的代码是人类可读的，那么它非常非常有用，这样人们就可以在代码生成过程中发现问题。毕竟，有人必须编写代码才能生成代码。这不是凭空发生的。

一次生成代码

并非所有源代码生成都是生成某些代码，然后再不对其进行处理的情况。然后在需要更新时从原始源重新生成它。

有时您只生成一次代码，然后丢弃原始源，然后继续维护新源。

将代码从一种语言移植到另一种语言时，有时会发生这种情况。特别是如果您不希望以后再移植原始文档中的新更改（例如，旧语言代码将不被保留，或者它实际上是完整的（例如，在具有某些数学功能的情况下））。

一种常见的情况是编写一个代码生成器来执行此操作，实际上可能只正确翻译了90％的代码。然后最后10％需要手工修复。这比手动翻译100％要快得多。

此类代码生成器通常与全语言翻译器（如Cython或f2c）生成的代码生成器类型非常不同。由于目标是使维护代码一次。通常将它们作为1 off来制作，以完全执行它们必须要做的事情。在许多方面，它是使用正则表达式/查找替换来移植代码的下一级别版本。您可以说“工具辅助的移植”。

仅从网站抓取一次生成代码。

密切相关的是，如果您是从某些源中生成代码，则不想再次访问。例如，如果生成代码所需的动作是不可重复的或不一致的，或者执行这些动作的成本很高。我现在正在研究两个项目： DataDeps.jl和 DataDepsGenerators.jl。

DataDeps.jl帮助用户下载数据（如标准ML数据集）。为此，我们需要一个称为RegistrationBlock的东西。那是一些代码，指定一些元数据，例如从何处下载文件，校验和，以及一条消息，向用户解释任何条款/条件/数据的许可状态。

编写这些块可能很烦人。这些信息通常可以在托管数据的网站上（结构化或非结构化）中获得。因此，DataDepsGenerators.jl使用网络爬虫为承载大量数据的某些站点生成RegistrationBlockCode。

它可能无法正确生成它们。因此，使用生成的代码的开发人员可以并且应该对其进行检查和更正。奇怪的是，他们想确保它没有遗漏例如许可信息。

重要的是，使用DataDeps.jl的用户/开发人员无需安装或使用webscraper即可使用生成的RegistrationBlock代码。（不需要下载和安装网络爬虫可以节省大量时间。尤其是对于CI运行而言）

一次生成源代码不是反模式。它通常不能用元编程代替。

“源”代码的生成指示所生成的语言的缺陷。使用工具来克服这种反模式吗？绝对不是-让我解释一下。

通常使用代码生成，因为存在一个更高级别的定义，该定义可以描述生成的代码，而无需使用比更低级别的语言更详细的代码。因此，代码生成有助于提高效率和简洁性。

当我编写c ++时，之所以这样做，是因为与使用汇编程序或机器代码相比，它使我可以更高效地编写代码。机器代码仍然由编译器生成。刚开始，c ++只是生成C代码的预处理器。通用语言对于生成通用行为非常有用。

同样，通过使用DSL（特定领域语言），可以编写简洁的代码，但可能仅限于特定任务的代码。这将使生成正确的代码行为变得不那么复杂。记住，代码是到达终点的手段。开发人员正在寻找的是一种生成行为的有效方法。

理想情况下，生成器可以从易于操作和理解的输入中创建快速代码。如果满足此要求，则不使用生成器是反模式。这种反模式通常源于“纯”代码是“更清洁”的概念，这与木材工人或其他工匠可能会考虑使用电动工具或使用CNC来“生成”工件的方式非常相似（认为是金色的）。锤子）。

另一方面，如果生成的代码的源代码难以维护或生成的效率不够高，则用户将陷入使用错误工具的陷阱（有时是因为同样的金锤子）。

源代码生成绝对确实意味着生成的代码是数据。但这是一流的数据，程序其余部分可以操纵的数据。

据我所知，集成到源代码中的两种最常见的数据类型是有关窗口的图形信息（各种控件的数量和位置）和ORM。在这两种情况下，通过代码生成进行集成都使操作数据变得更加容易，因为您不必经过额外的“特殊”步骤即可使用它们。

在使用原始（1984）Mac时，对话框和窗口定义是使用resouce编辑器创建的，该编辑器将数据保留为二进制格式。与“二进制格式”是Pascal相比，在应用程序中使用这些资源更加困难。

因此，不，源代码生成不是反模式，它可以使数据成为应用程序的一部分，从而使使用变得更容易。

当代码产生的成本超过实现的成本时，它就是一种反模式。这种情况发生在从A到B的生成时，其中A与B几乎是相同的语言，但是有一些小的扩展，只需用A编码即可完成，而无需花费所有定制工具为A到B建立阶段。

这种权衡更不利于在没有元编程功能（结构宏）的语言中生成代码，因为通过外部文本处理来实现元编程的复杂性和不足之处。

权衡取舍还可能与使用量有关。语言A可能与语言B完全不同，但是整个项目及其自定义代码生成器仅在一个或两个小地方使用A，因此总的复杂程度（A的小部分加上A-> B代码生成器，加上周围的构建阶段）超过了用B完成的解决方案的复杂性。

基本上，如果我们致力于代码生成，我们可能应该“变大或变笨”：使它具有实质性的语义，并大量使用它，或者不要打扰。

我没有清楚地看到这句话（我确实看到它被一两个答案触及了，但似乎不太清楚）

生成代码（就像您所说的那样，就好像它是数据一样）不是问题，这是一种将编译器用于次要目的的方法。

编辑生成的代码是您将遇到的最阴险，邪恶，恐怖的反模式之一。不要这样做。

充其量，编辑生成的代码会将大量不良代码引入您的项目中（整个代码集现在是真正的源代码-不再是数据）。最糟糕的是，拉入程序的代码是高度冗余的，名称不正确的垃圾，几乎完全无法维护。

我想第三类是您使用过一次的代码（gui生成器？），然后进行编辑以帮助您入门/学习。这只是每个步骤的一小部分-可能是一个不错的开始，但是您的GUI生成器将针对使用“可生成的”代码，对于您作为程序员而言，这不是一个很好的开始-此外，您可能会试图再次将其用于第二个GUI，这意味着将多余的SOURCE代码提取到您的系统中。

如果您的工具足够聪明，可以禁止对生成的代码进行任何编辑，那就去吧。如果没有，我将其称为最糟糕的反模式之一。

代码和数据都是：信息。

数据就是您所需要的形式（和价值）的信息。代码也是信息，但采用间接或中间形式。本质上，代码也是数据的一种形式。

更具体地说，代码是信息，这些信息使机器可以自己摆脱人们对信息的处理。

最重要的动机是使人们摆脱信息处理的压力。中间步骤是可以接受的，只要它们使生活变得轻松即可。这就是存在中间信息映射工具的原因。像代码生成器，编译器，编译器等。

为什么要生成源代码？为什么不使其成为可以接受参数并对其执行操作的函数呢？

假设有人为您提供了这样的映射功能，但其实现对您来说却很模糊。只要函数按承诺工作，您是否会在内部生成源代码？

如果可以生成某些东西，那么那是数据，而不是代码。

由于您稍后在代码中规定数据是数据，因此您的主张简化为“如果可以生成某些内容，则该内容不是代码”。那么，您会说C编译器生成的汇编代码不是代码吗？如果碰巧恰好与我手工编写的汇编代码相符怎么办？如果您愿意的话，欢迎您去那里，但我不会和您一起去。

让我们从“代码”的定义开始。在不太技术的情况下，出于讨论目的，一个很好的定义是“用于执行计算的机器可操作指令”。

鉴于此，对源代码生成的整个想法不是一种误解吗？

好吧，是的，您的初始主张是无法生成代码，但我拒绝该主张。如果您接受我对“代码”的定义，那么代码生成一般就不会有概念上的问题。

也就是说，如果有某个东西的代码生成器，那么为什么不将该东西变成一个可以接收所需参数并执行“将要生成的”代码将要执行的正确操作的适当函数呢？

嗯，这是一个完全不同的问题，是关于采用代码生成的原因，而不是其本质。您正在提出一种替代方案，而不是编写或使用代码生成器，而是编写一种直接计算结果的函数。但是用什么语言呢？任何人都直接用机器代码编写的日子已经一去不复返了，如果您用任何其他语言编写代码，那么您将依靠编译器和/或汇编器形式的代码生成器来生成实际运行的程序。

那么，为什么您更喜欢用Java或C或Lisp或其他语言编写？甚至汇编程序？我断言，这至少部分是因为这些语言为数据和操作提供了抽象，从而使表达要执行的计算的细节变得更加容易。

大多数高级代码生成器也是如此。典型的案例可能是扫描器和解析器生成器，例如lex和yacc。是的，您可以直接使用C或您选择的其他某种编程语言（甚至包括原始机器代码）编写扫描器和解析器，有时也可以。但是对于任何非常复杂的问题，使用高级的专用语言（例如lex或yacc）会使手写代码更易于编写，阅读和维护。通常也要小得多。

您还应该考虑“代码生成器”的确切含义。我认为C预处理和C ++模板的实例化是代码生成中的练习。你反对这些吗？如果没有，那么我认为您需要执行一些心理体操工作，以合理地接受这些内容，但拒绝其他形式的代码生成。

如果这样做是出于性能原因，那么这听起来像是编译器的缺点。

为什么？您基本上认为，应该有一个通用程序，用户向其提供数据，有些程序被归类为“指令”，而另一些程序被归类为“输入”，然后该程序将继续执行计算并发出更多的数据，我们称之为“输出”。（从某种角度来看，可以将这样的通用程序称为“操作系统”。）但是为什么您认为编译器在优化通用程序方面应该与在优化更专业的程序方面一样有效。程序？这两个程序具有不同的特性和不同的功能。

如果要完成两种语言之间的桥梁，那么这听起来像缺少接口库。

您说好像拥有通用度接口库一定是一件好事。也许可以，但是在许多情况下，这样的库很大，难以编写和维护，甚至可能很慢。如果实际上不存在这种野兽可以解决眼前的特定问题，那么当代码生成方法可以更快，更轻松地解决问题时，您是谁坚持要创建一个野兽呢？

我在这里想念什么吗？

我认为有几件事。

我知道代码也是数据。我不明白的是，为什么要生成源代码？为什么不使其成为可以接受参数并对其执行操作的函数呢？

代码生成器将用一种语言编写的代码转换为使用另一种通常是较低级语言的代码。然后，您要问的是，人们为什么要使用多种语言编写程序，尤其是为什么他们可能想要混合主观不同级别的语言。

但是我已经谈到了。一个人为特定任务选择一种语言，部分是基于该任务的清晰度和表现力。由于较小的代码平均具有较少的错误并且更易于维护，因此至少在大规模工作中也倾向于使用高级语言。但是，复杂的程序涉及许多任务，通常可以用一种语言更有效地解决其中的一些任务，而用另一种语言更有效或更简洁地解决其他任务。使用正确的工具完成工作有时意味着使用代码生成。

在您的评论范围内回答问题：

编译器的职责是采用以人类可读形式编写的代码，并将其转换为机器可读形式。因此，如果编译器无法创建有效的代码，则编译器将无法正确执行其工作。错了吗

编译器永远不会为您的任务而优化。这样做的原因很简单：它经过优化可以执行许多任务。这是许多人用于完成许多不同任务的通用工具。一旦知道您的任务是什么，就可以以特定于域的方式处理代码，从而权衡编译器无法做到的事情。

举例来说，我开发了可能需要分析师编写一些代码的软件。他们可以用C ++编写算法，并添加他们依赖的所有边界检查和提示技巧，但这需要对代码的内部工作有很多了解。他们宁愿写一些简单的东西，然后让我抛出一个算法来生成最终的C ++代码。然后，我可以做一些奇特的技巧来最大化性能，例如静态分析，这是我永远都不会期望我的分析师经历的。代码生成使他们能够以特定于域的方式进行编写，这使他们比任何通用工具都更容易将产品推向市场。

我也做了完全相反的事情。我还要完成另一项任务，即“不生成代码”。我们仍然希望使使用该软件的人员的工作变得轻松，因此我们使用了大量的模板元编程来使编译器即时生成代码。因此，我只需要通用的C ++语言即可完成工作。

但是，有一个陷阱。保证错误可读是非常困难的。如果您曾经使用过模板元编程代码，那么您会知道，一个无辜的错误会生成一个错误，该错误需要100行无法理解的类名和模板参数来了解出了什么问题。这种效果如此明显，以至于建议的语法错误调试过程是“滚动错误日志，直到看到自己的文件第一次出现错误为止。转到该行，斜视一下，直到意识到自己要做什么为止。做错了。”

如果我们使用代码生成功能，我们将拥有更强大的错误处理能力以及人类可读的错误。这就是生活。

有几种使用代码生成的不同方式。它们可以分为三大类：

• 生成另一种语言的代码，作为编译过程中某个步骤的输出。对于典型的编译器，这将是一种较低级的语言，但对于编译为JavaScript的语言，则可能是另一种高级语言。
• 在编译过程中，以源代码语言生成或转换代码。这就是宏的作用。
• 使用与常规编译过程分开的工具生成代码。此代码的输出是与常规源代码一起作为文件存储并与之一起编译的代码。例如，可能从数据库模式自动生成ORM的实体类，或者可能从接口规范（例如SOAP的WSDL文件）生成数据传输对象和服务接口。

我猜您正在谈论第三种生成的代码，因为这是最有争议的形式。在前两种形式中，生成的代码是一个中间步骤，它与源代码非常清晰地分开。但是在第三种形式中，源代码和生成的代码之间没有形式上的分隔，只是生成的代码可能带有注释，即“请勿编辑此代码”。仍然存在开发人员编辑生成的代码的风险，这确实很丑陋。从编译器的角度来看，生成的代码是源代码。

但是，这种形式的生成代码在静态类型的语言中可能确实有用。例如，当与ORM实体集成时，为数据库表使用强类型的包装器真的很有用。当然，您可以在运行时动态处理集成，但是会丢失类型安全性和工具支持（代码完成）。静态类型语言的一个主要优点是在编写类型时（而不只是在运行时）对类型系统的支持。（相反，这种类型的代码生成在动态类型的语言中不是很普遍，因为与运行时转换相比，在这种语言中它没有任何好处。）

也就是说，如果有某个东西的代码生成器，那么为什么不将该东西变成一个可以接收所需参数并执行“将要生成的”代码将要执行的正确操作的适当函数呢？

因为类型安全和代码完成是您在编译时（以及在IDE中编写代码时）想要的功能，但是常规函数仅在运行时执行。

但是，可能有一个中间立场：F＃支持类型提供程序的概念，它基本上是在编译时以编程方式生成的强类型接口。这个概念可能会替代代码生成的许多用途，并提供更清晰的关注点分离。

处理器指令集从根本上是必须的，但是编程语言可以是声明性的。运行以声明性语言编写的程序不可避免地需要某种类型的代码生成。如本答案及其他中所述，以人类可读的语言生成源代码的主要原因是要利用编译器执行的复杂优化。

如果可以生成某些东西，那么那是数据，而不是代码。

您弄错了方法。它应该读

如果可以将某些内容输入到可解释器的生成器中，那么该内容就是代码，而不是数据。

它是该编译阶段的源格式，接收器格式仍是代码。