首页 / 知识

关于不可知的语言：生成的代码是否需要人类可读？

2023-04-15 09:11:00

Does generated code need to be human readable?

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

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

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

但是，如果您生成的代码中包含了少量的简单逻辑，该怎么办？

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

是的，绝对！我什至可以给您讲一个故事，以解释为什么人们能够轻松阅读自动生成的代码很重要...

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

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

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

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

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

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

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

实际上，使生成的代码"不可读"可能是一个优势，因为它将使人们不愿"破解"生成的代码，而是在代码生成器中实现他们的更改，这非常有用。每当您出于任何原因而需要重新生成代码而又不丢失所做更改的时候，您的同事便会因为他认为所生成的代码已"完成"。

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

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

我想说代码必须是人类可读的，除非您的代码生成工具具有出色的调试器，否则您(或不幸的同事)可能会深深地陷入代码中，以试图追踪它！系统中难以捉摸的错误。我自己对"从UML中获取代码"的游览使我口中苦涩，因为我无法掌握所谓的"花哨"调试过程。

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

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

-亚当

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

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

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

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

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

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

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

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

生成的代码不会被开发人员看到。例如，定义布局的xml-ish代码(请考虑.frm文件或SSIS生成的可怕文件)

生成的代码旨在作为类的基础，稍后您的开发人员将对其进行自定义，例如，生成代码以减少打字乏味

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

类和接口，无论您认为对开发人员有多"超限"，几乎都肯定会落入生成的代码类型2中。它们将在调试器的另一点击中-应用代码格式设置至少可以使您在编译器命中那些生成的类时轻松进行调试过程

我认为答案是：取决于。

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

就个人而言，如果您只想构建代码，将其编译为可执行文件，然后将中间代码扔掉，那么我看不出有什么用做得太漂亮了。

生成的代码就是代码，因此没有理由不可读和格式化任何代码。这特别便宜，尤其是在生成的代码中：您不需要自己应用格式设置，生成器每次都为您完成！：)

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

由于上面已经提到的大量理由，绝对可以。还有一点是，如果您的代码需要由评估员检查(出于安全性和可靠性问题)，那么如果代码可以人工重做则更好。如果不是这样，评估者将拒绝评估它，而您的项目将被当局修改。然后，唯一的解决方案是评估...代码生成器(这通常要困难得多；))

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

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

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

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

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

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

通常，如果您生成的代码以后需要人工修改，则必须尽可能地易于阅读。但是，即使将要生成并且不再被触及的代码，它仍然需要足够的可读性，以便您(作为编写代码生成器的开发人员)可以调试生成器-如果生成器吐出了错误的代码，如果难以理解，可能很难找到。

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