我正在开发一种工具，该工具将为接口和实现该接口的几个类生成源代码。我的输出并不是特别复杂，因此要使输出符合我们的常规代码格式标准并不困难。

但是，这让我开始思考：自动生成的代码需要如何可读？什么时候应该花更多的精力来确保生成的代码易于被人类阅读和理解？

就我而言，我正在生成的类本质上只是用于存储与构建另一部分有关的某些数据的容器，并带有获取数据的方法。从来没有人需要查看类本身的代码，他们只需要调用类提供的各种getter。因此，如果代码"干净"，格式正确且易于人阅读，则可能不太重要。

但是，如果我们生成的代码中包含少量简单逻辑，会发生什么情况？

解决方案

回答

我认为对于生成的代码而言，使其可读并遵循正常的编码样式也同样重要。在某个时候，有人或者需要调试代码，或者以其他方式查看"幕后"情况。

回答

将来很可能有人会仔细检查一下代码的作用。因此，使其易于理解是一件好事。

我们可能还需要在每个生成的文件的顶部添加注释，以说明生成此文件的方式，原因以及目的。

回答

我认为这取决于如何使用生成的代码。如果该代码不是供人类阅读的，即每当发生更改时就会重新生成该代码，我认为它不必可读。但是，如果将代码生成用作"常规"编程的中间步骤，则生成的代码应具有与其余源代码相同的可读性。

实际上，使生成的代码"不可读"可能是一个优势，因为它会阻止人们"黑客"生成的代码，而宁愿在代码生成器中实现他们的更改，这在我们需要重新生成代码时非常有用并避免失去所做的更改，因为同事认为生成的代码已"完成"。

回答

通常，如果我们生成的代码以后需要人工修改，则它必须尽可能地易于阅读。但是，即使将要生成并且永远不会被触及的代码，仍然需要足够的可读性，以便我们(作为编写代码生成器的开发人员)可以在生成器吐出不良代码的情况下调试生成器，这可能很难找出难以理解的地方。

回答

我认为，花一些额外的时间使其易于阅读，以使其易于调试是值得的。

回答

我要说的是，代码必须是人类可读的，除非代码生成工具具有出色的调试器，否则我们(或者不幸的同事)可能会深深地插在代码中，试图追踪这种难以捉摸的错误在系统中。我自己对"来自UML的代码"的浏览使我口中苦涩，因为我无法掌握所谓的"花哨"调试过程。

回答

生成的代码应该是可读的(格式等通常可以由半个体面的IDE处理)。在代码生命周期的某个阶段，它将被某人查看，他们将想要理解它。

回答

我认为对于工作非常简单的数据容器或者对象，人类的可读性不是很重要。

但是，一旦开发人员可能不得不阅读代码以了解事情如何发生，就必须使其可读。如果逻辑有错误怎么办？如果没有人能够阅读和理解代码，那么人们将如何发现它呢？我会为更复杂的逻辑部分生成注释以表达意图，因此更容易确定是否确实存在错误。

回答

逻辑应该始终可读。如果其他人将要阅读该代码，请尝试将自己摆在自己的位置，看看我们是否可以在不阅读特定代码的情况下完全理解高(低)代码。

我不会花太多时间来阅读永远不会被阅读的代码，但是如果时间不是太多，我将遍历生成的代码。如果没有，请至少发表评论以弥补可读性的损失。

回答

如果必须调试自己生成的代码，我们将自杀。不要开始以为你不会。请记住，当我们信任自己的代码来生成代码时，我们已经在系统中引入了两个错误。我们已经两次插入了自己。

绝对没有理由不使其具有人类可解析性，那么为什么我们要在世界上这样做呢？

-亚当

回答

如果此代码可能会被调试，那么我们应该认真考虑以人类可读的格式生成它。

回答

是的，它确实。
首先，我们可能需要对其进行调试-我们将可以轻松进行调试。
其次，它应遵守我们在商店中使用的所有编码约定，因为有一天可能需要手动更改代码，从而成为人工代码。当代码生成工具不能满足特定需求时，通常就不会出现这种情况，并且仅出于此目的而认为不值得对其进行修改。

回答

生成的代码有不同类型，但是最简单的类型是：

• 生成的代码不会被开发人员看到。例如，定义布局的xml-ish代码(请考虑.frm文件或者SSIS生成的可怕文件)
• 生成的代码旨在作为类的基础，稍后开发人员将对其进行自定义，例如，生成代码以减少打字乏味

如果要使用后者，则绝对希望代码对人类可读。

类和接口，无论我们认为对开发人员的"限制"如何，几乎可以肯定都属于生成的代码类型2. 它们将在调试器的另一点受到打击-应用代码格式最少当编译器命中那些生成的类时，可以简化调试过程

回答

生成代码的全部目的是要做一些"复杂"的事情，而这在某些高级语言中更容易定义。由于生成了该代码，因此该生成代码的实际维护应在生成代码的子例程中进行，而不是在生成代码中。

因此，人类可读性应具有较低的优先级；诸如运行时速度或者功能之类的事情要重要得多。当我们查看诸如bison和flex之类的工具时，尤其是这种情况，它们使用生成的代码预先生成快速的查找表来进行模式匹配，而这对于手动维护来说简直是疯狂的。

回答

就像这里的其他所有人一样，我想说的是可读性。在生成过程中，它不会花费任何额外的费用，当我们(或者后继者)进行挖掘时，我们将不胜感激。

对于一个真实的例子，请看一下Visual Studio生成的任何内容。格式正确，带有注释和所有内容。

回答

查找主动代码生成与被动代码生成。关于被动代码生成，绝对是的，总是如此。关于主动代码生成，当代码达到透明的目的(就像记录的API一样起作用)时，则为否。

回答

生成的代码就是代码，没有任何理由不应该使代码可读且格式正确。这特别便宜，尤其是在生成的代码中：我们不需要自己设置格式，生成器每次都为我们完成格式化！ :)

作为第二种选择，如果我们真的那么懒，那么在将代码写入磁盘之前如何通过所选的美化工具将代码进行管道传输以确保至少一定程度的一致性。尽管如此，我认识的几乎所有优秀程序员都相当书呆子地格式化他们的代码，这有一个很好的理由：没有纯写代码。

回答

绝对是的，因为上面已经说了很多理由。还有一点是，如果代码需要由评估员检查(出于安全性和可靠性问题)，那么代码可以人工重做会更好。如果没有，评估者将拒绝评估，并且项目将被当局修改。然后，唯一的解决方案是评估...代码生成器(通常要困难得多；)

回答

是的，一点没错！;我什至可以为我们提供一个故事，以解释为什么人们能够轻松阅读自动生成的代码很重要...

我曾经有机会从事一个新项目。现在，开始编写代码时需要做的第一件事就是在数据库之间建立某种连接和数据表示。但是，不仅仅是有人手工编写此代码，我们还有人开发了自己的代码生成器，可以根据数据库模式自动构建基类。真是太整齐了，编写所有这些代码的繁琐工作现在已经不在我们的手中了……唯一的问题是，生成的代码对普通人来说远非易读。

当然，我们不是那样做的，因为嘿，它为我们节省了很多工作。
但是过了一段时间，事情开始出错，从用户输入中错误地读取了数据(或者我们认为是这样)，而在我们仅读取的地方，数据库内部发生了损坏。奇怪..因为读取不会更改任何数据(再次，所以我们认为)...

像任何优秀的开发人员一样，我们开始质疑自己的代码，但是经过几天的搜索..即使重写了代码，我们也找不到任何东西...然后它突然出现了，自动生成的代码被破坏了！

因此，现在还有一个更大的任务在等待着我们，检查自动生成的代码，没有理智的人可以在合理的时间内理解...我说的是非缩进的，非常糟糕的样式代码，具有不可发音的变量和函数名...它事实证明，与其自己弄清楚代码的实际工作方式，不如自己重写代码甚至更快。

最终，编写代码生成器的开发人员稍后对其进行了重新制作，因此，它可以生成可读代码，以防万一像以前那样出错。

这是我刚刚找到的有关当前主题的链接。我正按时地寻找到"实用程序员"书中某一章的链接，以指出为什么我们首先看代码。

回答

未提及的问题的另一方面是，所生成的代码也应该是"版本控制友好的"(在可行的范围内)。

我发现多次检查生成的代码与源代码中的差异很有用。

这样，我们甚至有时可能会在生成代码的工具中发现错误。

回答

这取决于代码将仅由编译器读取还是由人工读取。此外，代码是否应该是超快速的还是可读性是否重要也很重要。如有疑问，请付出额外的努力来生成可读代码。

回答

我认为答案是：这取决于。

*这取决于我们是否需要人工配置和存储生成的代码。例如，人们很少保留或者配置c编译器的目标代码输出，因为他们知道他们每次都可以从源代码中复制它。我认为这里可能有一个类似的比喻。
*这取决于我们是否需要按照某些标准对代码进行认证，例如Misra-C或者DO178.
*这取决于源代码是在每次编译代码时通过工具生成的，还是在以后存储在构建中的源代码。

就个人而言，如果我们只想构建代码，将其编译为可执行文件，然后丢弃中间代码，那么使它变得太漂亮我看不到任何意义。