理论上，源代码不应包含超过0,1和空字符串的硬编码值。 在实践中，我发现在非常紧张的交付时间内很难避免所有硬编码的值，所以我最终使用了一些并感到有点内疚。
如何协调避免硬编码值与交货时间紧张？
为了避免硬编码你应该
当然，并非所有值都有资格移动到配置文件。 对于那些你应该使用编程语言提供的结构，如（常量，枚举等）。
刚看到答案使用“Constatn接口”。 对海报和选民充分尊重，但不建议这样做。 您可以在以下位置阅读更多相关信息
这需要一些规划，在大多数情况下，它只是具有配置文件，或者可能是存储关键配置项的数据库表。 我没有发现你有“拥有”硬编码值的任何理由，并且它不会花费你太多额外的时间来卸载到一个配置机制，以便紧密的时间线是一个有效的借口。
硬编码值的问题在于，有时特定代码依赖于它们并不是obvoius。 例如，在java中，可以将所有常量移动到单独的接口中，并将特定常量分隔为内部子接口。 这很方便也很明显。 此外，只需使用IDE工具（“查找用法”功能）并更改或重构它们，就可以轻松找到常量用法。
这是一个例子：
public interface IConstants {
public interface URL {
String ALL = "/**";
}
public interface REST_URL {
String DEBUG = "/debug";
String SYSTEM = "/system";
String GENERATE = "/generate";
}
}
引用非常易读： IConstants.REST_URL.SYSTEM
大多数非平凡的企业项目都有一些属性或配置选项的中心概念，它们已经负责从文件/数据库加载选项。 在这些情况下，通常很简单（例如，不到5分钟的工作）来扩展它以支持您需要的新属性。
如果您的项目没有，那么：
硬编码的确没有借口 - 它最多只能节省几分钟，如果你的项目截止日期是几分钟，那么你就会遇到比如何编码可配置性更大的问题。
不可否认，我在目前的业余爱好项目中对很多东西进行了硬编码。 配置文件是可笑容易使用而不是（至少与Python，它配备了一个伟大而简单的.cfg分析器），我只是不打扰，因为我相信99％，我将永远不会有改变他们使用它们-即使这个假设被证明是错误的，它也足够小，可以用合理的努力来重构它。 然而，对于更大/更重要的东西，我永远不会输入if foo == "hardcoded bar" ，而是if foo == cfg.bar （可能有更有意义的cfg名称）。 Cfg是一个全局单例（是的，我知道...），它在启动时输入.cfg文件，下次一些标记值更改时，您更改配置文件而不是源。
使用动态/反射语言，当您向其添加另一个值时，甚至不需要更改加载.cfg的部分 - 使其使用文件中的所有条目动态填充cfg对象（或使用散列映射，为此事情）并完成。
这里有2条建议：首先，如果您正在使用像C这样的语言处理嵌入式系统。只需编写一个编码约定，将#define用于任何字符串或常量。 所有#define都应该归类为.h文件。 这应该足够了 - 不是太复杂，但足以维护。 您不需要修改代码行之间的所有常量。
其次，如果您正在处理具有数据库访问权限的应用程序。 只需将所有常量值保存在数据库中即可。 您只需要一个非常简单的接口API来进行检索。
通过简单的技巧，可以扩展这两种方法以支持多语言功能。
这个问题背后的假设在我看来是无效的。
对于大多数软件，配置文件更难以更改源代码。 对于广泛安装的软件来说，这可能很容易造成百万倍的困难：很容易就会有很多文件挂在用户安装上，而你几乎没有知识，也无法控制。
在软件中使用数字文字与具有功能或算法文字没有区别：它只是源代码。 任何软件都有责任确保这些价值正确。
失败使他们至少可以维护：有条不紊和有组织。
使它们可配置是一种最后的沟通妥协，如果你的时间紧迫，你可能会被迫进入。