将数据值硬编码到程序中是否有优势？

我是一个自学成才的新手程序员，因此，如果我不喜欢程序员的话，我深表歉意。

我正在从事一个项目，在该项目中，我将向开发人员提供不断更新的数据，这些开发人员实际上将创建一种工具，用于根据对数据的查询生成报告。

似乎每个参与人员都认为他们需要将数据值（不是模式，而是域/值本身）硬编码到报告生成程序中。

例如，假设我们正在报告人员情况；该报告将分为几类，每个部门都有一个标题，然后在每个部门标题下将是职务的子标题，然后在每个子标题下将是雇员列表。开发人员希望对部门和职位进行硬编码。另一方面，我认为他们可以/将在运行时查询这些事情，对它们进行排序，并根据存在的值动态生成报告标题。

由于潜在价值的列表将随着时间而变化（例如，将创建/重命名部门，将添加新的职务），因此需要不断更新代码。在我看来，我们可以跳过代码维护步骤，并动态组织报告。

由于我不是开发人员，所以我想知道自己缺少什么。将值硬编码到这样的工具中可能有什么优势？这通常是程序的设计方式吗？

维基百科：

硬编码（也称为硬编码或硬编码）是指软件开发实践，即可能仅在回顾时才将可能被视为输入或配置数据的内容直接嵌入到程序或其他可执行对象的源代码中，或数据，而不是从外部源获取数据或使用给定输入在程序本身中生成数据或格式化。

硬编码被认为是反模式。

硬编码被认为是一种反模式，当输入数据或所需的格式发生更改时，硬编码就需要更改程序的源代码，这对于最终用户而言，通过程序外部的某种方式更方便地更改细节可能更为困难。

有时您无法避免，但它应该是暂时的。

经常需要硬编码。程序员可能没有针对最终用户的动态用户界面解决方案，但仍必须提供功能或发布程序。这通常是暂时的，但是从短期的意义上来说，确实可以解决交付代码的压力。以后，进行软编码以允许用户传递参数，这些参数为最终用户提供了一种修改结果或结果的方法。

• 消息的硬编码使程序国际化变得困难。
• 硬编码路径使其很难适应另一个位置。

硬编码的唯一优点似乎是快速交付代码。

真？没有可能的有效用例？

尽管我同意硬编码通常是一种反模式，或者至少是一种非常难闻的代码味道，但在很多情况下它是有道理的：

• 简单（YAGNI），
• 输入实际上是恒定的，并且永远不会改变（即，它代表自然或业务常数，或者近似于1。例如0，PI，...），
• 嵌入式软件（记忆和分配限制会浮现在脑海），
• 安全软件（这些值不可用和/或不易于解码或逆向工程，例如加密令牌和盐），
• 生成的代码（您的预处理器或生成器是可配置的，但会吐出带有硬编码值的代码），
• 可能还有更多。

还是一个反模式？过度工程也是如此！这与软件的预期寿命有关！

并不是说我有很多很好的理由，通常我会不愿意使用硬编码的值。但是有些人出于正当的理由很容易获得通过。

并且不要以为简单/ YAGNI太琐碎而忽略了第一个：可能没有理由为一个很好的简单脚本实现疯狂的解析器和值检查器，该脚本很好地在狭窄的用例中完成了一项工作。

很难找到平衡。有时候，您没有预料到软件会比最初的简单脚本变得强大并且持续时间更长。但是，通常情况却恰恰相反：我们过度设计了东西，并且一个项目的搁置速度比您阅读Pragmatic Programmer的速度还快。与早期的原型相比，您浪费了时间和精力。

这就是反模式的卑鄙之处：它们同时存在于频谱的两个极端中，并且其外观取决于查看代码的人员的敏感性。

有时可以对值进行硬编码。例如，有些数字（例如0）或一个或多个n ^ 2-1值用于位掩码，出于算法目的，它们必须是某些值。将这样的值允许为可配置的值没有任何价值，只会带来问题的可能性。换句话说，如果更改值只会破坏事情，则可能应该对其进行硬编码。

在您提供的示例中，我看不到硬编码在哪里有用。您提到的所有内容（包括标题）都已经/应该已经存在于数据库中。如果不存在，甚至可以驱动显示的内容（例如排序顺序）。

要实现一个健壮的解决方案，以允许最终用户可以对这些值进行硬编码而改为可配置，则需要对这些值进行健壮的验证。他们是否输入了空字符串？他们是否在非数字的地方输入了应该是数字的地方？他们在做SQL注入吗？等等。

硬编码避免了很多此类风险。

这并不是说硬编码始终是，甚至经常是一个好主意。这只是要考虑的因素之一。