生成的代码是否需要人类可读？

Question

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

但是这让我想到：自动生成的代码需要具有人类可读性吗？什么时候应该花费额外的努力来确保生成的代码很容易被人类阅读和理解？

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

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

Answer 1

我认为生成的代码可读并且遵循正常的编码风格同样重要。在某些时候，某人要么需要调试代码，要么在“幕后”看到正在发生的事情。

Answer 2

是的！绝对是！我甚至可以为你讲一个故事，解释为什么人类可以轻松阅读自动生成的代码这一点很重要......

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

当然我们没有这个，因为嘿，它只是为我们节省了很多工作。 但是一段时间后事情开始出错，数据被错误地从用户输入中读取（或者我们认为），当我们仅读取时，数据库内部发生了损坏。奇怪..因为阅读不会改变任何数据（再次，所以我们认为）......

像任何优秀的开发人员一样，我们开始质疑我们自己的代码，但经过几天的搜索...甚至重写代码，我们找不到任何东西......然后它就恍然大悟，自动生成的代码被破坏了！

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

最终，编写代码生成器的开发人员稍后会重新编写代码生成器，因此它现在会生成可读代码，以防万一出现问题。

以下是a link I just found关于手头的主题;我正在寻找"pragmatic programmer" book章节中的一个章节的链接，以指出我们为什么首先查看我们的代码。

Answer 3

我认为这取决于生成代码的使用方式。如果代码不是由人类阅读，即每当某些内容发生变化时它就会重新生成，我认为它不必具有可读性。但是，如果您使用代码生成作为“正常”编程的中间步骤，则生成的可能与源代码的其余部分具有相同的可读性。

事实上，使生成的代码“不可读”可能是一个优势，因为它会阻止人们“黑客”生成代码，而是在代码生成器中实现他们的更改 - 这在您需要时非常有用无论出于何种原因重新生成代码，并且不会丢失您的同事所做的更改，因为他认为生成的代码已“完成”。

Answer 4

查看active code generation与passive code generation。关于被动代码生成，绝对是，永远。关于活动代码生成，当代码实现透明的目标时，其行为与记录完全相同API，然后没有。

Answer 5

是的。 首先，您可能需要对其进行调试 - 您将自己轻松实现。 其次，它应该遵循您在商店中使用的任何编码约定，因为有一天代码可能需要手动更改，从而成为人工代码。当您的代码生成工具没有涵盖您需要的某个特定事物时，通常会出现这种情况，并且仅为此目的而修改该工具并不值得。

Answer 6

未提及的问题的另一个方面是生成的代码也应该是“版本控制友好的”（尽可能）。

我发现在生成的代码和源代码中仔细检查差异很多次都很有用。

这样你甚至可以偶尔发现生成代码的工具中的错误。

Answer 7

我会说代码必须是人类可读的，除非你的代码工具有一个优秀的调试器你（或不幸的同事）可能会被代码中的一个腰部试图跟踪那个哦在系统中如此难以捉摸的bug。我自己的'UML代码'游览让我感到痛苦，因为我无法理解所谓的'花式'调试过程。

Answer 8

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

绝对没有理由不让它人性化，所以你为什么要这样做？

- 亚当

Answer 9

生成代码的重点是做一些“复杂”的东西，这在某些更高级别的语言中更容易定义。由于它是生成的，因此生成的代码的实际维护应该在生成代码的子例程内，而不是生成的代码。

因此，人类可读性应该具有较低的优先级;运行速度或功能等内容更为重要。当您查看像bison和flex这样的工具时尤其如此，这些工具使用生成的代码预先生成快速查找表来进行模式匹配，这对于手动维护来说简直就是疯了。

Answer 10

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

*这取决于您是否需要将生成的代码配置并存储为人工制品。例如，人们很少保留或配置c编译器输出的目标代码，因为他们知道每次都可以从源代码中重现它。我想这里可能有类似的比喻。 *这取决于您是否需要将代码证明为某些标准，例如Misra-C或DO178。 *这取决于每次编译代码时是否通过工具生成源代码，或者是否存储它以便以后包含在构建中。

就个人而言，如果您只想构建代码，将其编译成可执行文件然后抛弃中间代码，那么我就看不出任何使它变得太漂亮的观点。

Answer 11

这取决于代码是仅由编译器还是由人类读取。此外，重要的是代码是否应该超快或可读性是否重要。如有疑问，请额外努力生成可读代码。

Answer 12

绝对是的，因为上面已经说过很多好的理由。还有一个问题是，如果您的代码需要由assesor检查（出于安全性和可靠性问题），那么如果代码是人类可重新定义的话，那就更好了。如果没有，评估员将拒绝对其进行评估，您的项目将被当局批准。然后唯一的解决方案是评估......代码生成器（通常要困难得多;））

Answer 13

生成的代码是代码，并且没有理由任何代码不应该是可读的并且格式良好。这很便宜，特别是在生成的代码中：你不需要自己应用格式化，生成器每次都为你做！ ：）

作为第二选项，如果您真的很懒，那么在将代码写入磁盘之前，通过您选择的美化实用程序来管理代码，以确保至少某种程度的一致性。尽管如此，我所知道的几乎所有优秀的程序员都非常迂腐地编写代码，这是有充分理由的：没有只写代码。

Answer 14

就像几乎所有其他人一样，我说让它变得可读。在你的生成过程中没有任何额外费用，而你（或你的继任者）在挖掘时会很感激。

对于一个真实世界的示例 - 查看Visual Studio生成的任何内容。格式良好，有评论和一切。

Answer 15

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

1. 生成的代码，开发人员无意看到。例如，定义布局的xml-ish代码（想想.frm文件，或SSIS生成的可怕文件）
2. 生成的代码，旨在成为稍后由开发人员自定义的类的基础，例如，生成代码以减少输入tedium

如果您正在制作后者，那么肯定希望您的代码具有人类可读性。

类和接口，无论你认为它们应该如何“禁止”，几乎肯定会属于生成的代码类型2.它们将被调试器在另一个点击中 - 应用代码格式当编译器遇到那些生成的类时，你可以轻松地完成调试过程

Answer 16

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

Answer 17

逻辑应始终可读。如果其他人要阅读代码，请尝试将自己置于原位，看看是否能够完全理解高（低）？级别的代码，而无需阅读特定的代码。

我不会花费太多时间使用永远不会被读取的代码，但如果不是太多时间我将通过生成的代码。如果没有，至少发表评论以弥补可读性的损失。

Answer 18

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

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

Answer 19

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

Answer 20

我认为花些额外的时间让它变得人性化，以便更容易调试是值得的。

Answer 21

通常，如果您生成的代码需要稍后进行人工修改，则需要尽可能具有人类可读性。但是，即使它的代码将被生成并且再也不会被触及，它仍然需要足够可读，以至于您（编写代码生成器的开发人员）可以调试生成器 - 如果您的生成器吐出错误代码，则可能很难追踪是否难以理解。

Answer 22

未来的某个人很可能想要查看代码的作用。所以让它有点可以理解是一件好事。

您还可能希望在每个生成的文件的顶部包含一条注释，说明该文件的生成方式和原因以及它的用途。