代码生成会提高代码质量吗？

争论代码生成，我正在寻找一些提高代码质量的方法示例。为了阐明代码生成的含义，我只能谈论我的一个项目：

我们使用XML文件描述数据库架构中的实体关系，因此它们可帮助我们生成ORM框架和HTML表单，可用于添加，删除和修改实体。

在我看来，由于减少了人为错误，它提高了代码质量。如果某些东西实现不正确，则会在模型中将其破坏，这是很好的，因为由于更多生成的代码也被破坏了，因此错误可能会更快出现。

由于要求我提供代码质量的定义，因此让我澄清一下，我的意思是软件质量。

软件质量：这不是一个属性，而是相互影响的许多属性，例如效率，可修改性，可读性，正确性，健壮性，可理解性，可用性，可移植性等。

代码生成器不能比编写该生成器的人生成更好的代码。

我对代码生成器的经验是，只要您不必编辑生成的代码，它们就可以了。如果您能坚持该规则，那您就走了。这意味着您可以放心和快速地可靠地重新生成系统的该部分，并在需要时自动添加更多功能。我想这可以算是质量。

我曾经听过一个关于代码生成器的论点，即一个程序员每天可以生成如此多的代码行，而使用代码生成器，他们可以生成数千行！显然，这不是我们使用生成器的原因。

我反过来说 -假设您正在编写有趣的应用程序，代码生成会降低代码质量。代码生成的本质是奖励那些千篇一律的，过分夸张的，过度指定的框架，这些框架在不持续依赖代码生成工具来不断生成更大，更复杂，更丑陋的代码束的情况下变得很难处理。尽管它可能是一个很好的工具，但实际上不应成为包装盒中的主要工具。

我认为自动代码生成和代码质量有些正交，不一定相互关联。

代码生成仅仅是解决特定技术任务的一种方式。是否提高代码质量很大程度上取决于您在做什么。

您的情况是代码生成的一个很好的例子，可以通过尽早发现潜在的错误来提高代码质量。

我可以再举一个例子，说明自动代码生成会降低代码质量。全能的ASP.NET WebForms。它通过将UI控件的层次结构转换为HTML标记来实现自动代码生成，这一切都是稳定，可预测和可管理的。

得出结论，在正确使用时，自动代码生成可以帮助提高代码质量。

代码生成本身并不会影响代码质量，而不会影响代码一致性。

生成的代码将在生成实例之间保持一致。如果生成器被设计为发出高质量的代码，则生成的代码将始终具有良好的质量。但是，如果代码生成器发出质量差的代码，则您将始终得到错误的代码。

代码生成也可以用来更快地构建代码。然而，更快并不意味着更好。这可能意味着您可以更快地得到质量差的代码。

如果满足以下条件，则代码生成很好：

• 生成的代码不应该被编辑
• 代码生成器为您提供了足够的灵活性来执行所需的操作
• 代码生成器的输入语言比其他方式要好（例如，DRY）
• 即使是罗creates的代码生成器，也可以创建无需担心的良好可靠的代码

在这种情况下，您需要考虑的质量代码就是输入到生成器的代码。

对于质量的典型更改，质量的一个简单衡量标准是您需要执行多少手动编辑。越少越好。

由于DRY（不重复自己），因此提高了代码质量。

代码生成规则只编写一次；它们不会针对生成的每个代码实例进行硬编码，因此，只需稍加修改即可减少在复制/粘贴内容时出现人为错误的可能性。

我假设您是指专门为内部使用而使用的专有代码生成器，因为否则任何缺少机器代码的东西都是代码生成器。但是，您可以在这里：

我认为，与它生成的GLSL / HLSL代码（否则需要手写）相比，Blueprints中的节点图更易于维护并且更不容易出错，这是非常有争议的。

提出新的着色器的效率也更高，因为您可以实时视觉反馈更改图形时最终结果的外观。我绝对更希望以这种方式维护成千上万个用节点图表示的着色器，而不是GLSL / HLSL代码，而且我实际上比使用Blueprints更熟悉编写GLSL / HLSL。我认为，除了可能会立即捕捉到的轻微视觉故障外，实际上几乎不可能引起重大错误，因为“视觉语言”通常会以纯粹的功能样式强加合理的约束，例如，使着色器崩溃，至少是AFAIK（我当然不是蓝图专家）。

甚至没有“代码”可以维护了。您只需将节点放置在图形中并在它们之间绘制链接，瞧，它将为您生成着色器代码。谁维护着这些东西，然后说：“ 您知道，如果这是用GLSL代码而不是使用Blueprints编写的，那么我的生活会变得更加轻松，我将有更多的空闲时间。 ”可能永远不会。

就是说，我遇到了很多专有代码生成器，它们确实使生活变得更加艰难，使我学习了这种愚蠢的元语言，与使用生成的代码语言编写代码相比，它的好处是非常有限的（如果有的话）。对我来说，代码生成的一个迹象表明，它只是减少了少量样板，实际上并没有减少错误的可能性。您知道，如果它实际上引入了导致原始语言所没有的bug的新方法，那将尤其令人讨厌。但是，在某些情况下，例如上面的代码生成，生产率的提高是如此之大，以致于花费大量时间来处理细微的事情现在要花几分钱，甚至没人会回头再回头。

对我而言，对于Epic团队中的Blueprints专有开发而言，有一种比在世上为大众提供的许多多余的编程语言更合理的论点。

我要说的是，这可能会稍微提高质量，但会大大减少开发时间。有时，生成的代码不稳定，笨拙，或者只是很糟糕。在这些情况下，生成的代码会降低质量，并增加项目的测试/修复/回归测试时间。而且有些任务太复杂而无法轻易生成-生成器本身变成了一个完整的独立系统（可能比主项目更大，更复杂）。

代码生成器很好，但是要小心使用它们！

我曾经在一家非常依赖代码生成的商店里工作。在我看来，它使该项目的代码非常统一。在这方面，质量还可以。

但是，由于一切都必须通过生成器而不再允许您编写自定义代码时，我认为您失去了成为程序员的某些优势。

因此，我认为这肯定是一把双刃剑话题。是的，生成器之所以出色，是因为它们减少了错误并提高了代码标准，但是，它们也使“某些”程序员变得愚蠢，因为它们依赖于生成器而不必费心。

只是我的2美分。

除了马丁的答案，我还要补充一点，当您逐条记录地工作时，SQL代码生成非常好（从tab1中选择*，其中tab1.pkcolumn =：parameter，更新tab1 set [任意列数]，其中tab1.pkcolumn =：parameter等）。在这种情况下，您的ORM将大放异彩，因为确实需要重复生成SQL。

我主要担心的是元查询-查询对象的属性，ORM使用任何算法将其转换为SQL。非常相似的元查询可能会生成完全不同的SQL-并不能保证此生成的SQL是高性能的。

一种元查询语言，可以转换为另一种语言（SQL），该语言可以转换为查询计划以有效执行数据收集。并且生成的结果必须是对象，因此ORM必须实例化受影响的对象-这样它可以触发另一查询查询，以填充元查询本身未带来的对象的属性...

我完全同意那些说代码生成很好的人，只要您不必编辑（最好不必查看）生成的代码即可。

如果我们可以接受所生成的代码与手写的行数大致相同，并且可以说它没有错误，那么可能包含错误的行数就会减少。因此，代码质量应该提高了。

附录：当然，其他因素（例如执行时间）也可能起作用。

就个人而言，我已经编写了许多代码生成器，但从来没有将其作为初始方法。

一直以来，我都注意到现有代码中的重复模式，因此，生成器在添加新的但相似的代码并对其中的一些可变部分进行参数化时会使用一些现有代码。

在那种程度上，我生成的代码几乎与现有的手写代码相同（除了它倾向于更好地在视觉上布局和更统一，如果必须要看的话，我认为这有助于提高可读性）。

顺便说一句，我主张插入打开/关闭注释，这些注释指示代码已生成，包括工具及其维护者的详细信息。