你对硬编码的态度是什么？

Question

我的是这样的:

硬编码就是这样!我所有的问题都消失了.只需逐个编码即可.而问题又回来了.

我绝对讨厌它,但事实是"商界人士"倾向于喜欢它,因为它需要更少的时间来获得他们想要的东西.作为一个特别是在企业环境中工作的软件开发人员,大多数人都会说:"是的,为什么要打扰,只需要硬编码".你对硬编码的态度是什么？

Answer 1

硬编码是应该尽可能避免的.

如果您对代码进行硬编码,则会在很大程度上完全"破坏" 代码的可移植性.即使使用平台独立语言,您也无法说"编译一次,随处运行".由于它不是一个好的软件工程实践,我认为避免硬编码更好.

但我知道在某些情况下我们需要它,特别是在调试代码时.我建议的方法是:首先用硬代码开发代码,使其稳定并消除硬编码然后......

由于安全问题等原因,可能会出现一些我们需要硬编码的情况.您可能不被允许使用注册表,配置文件,因为它们可以增加攻击面.但我认为这是一种罕见的情况.

Answer 2

IT中不存在银子弹.

• 如果聪明就做.
• 如果它哑了就不要这样做.

如果有人告诉你做蠢事,保存电子邮件线程并保存你的工作

Answer 3

硬编码没有错,只要出于正确的原因就行了!

"正确行事"意味着将所有硬编码集中在一个或两个模块中.

对于C,定义codes.h for Java中的所有值都有一个codes.java类,它只是公共常量.

硬编码有几个"正当理由".

• 简单.
• 支持 - 如果您的值在外部配置文件中,则无法保护自己免受愚蠢配置的影响,并且您无法测试所有可能的配置,如果其硬编码,那么您就知道自己在处理什么.
• 性能.
• 可读性.您可以在编辑会话中看到您需要知道的所有内容!

还有几个原因可以避免复杂的配置文件.如果你有足够的参数和选项,你最终会用一种不太好的语言进行编程.

Answer 4

从概念上讲,我不喜欢太多的硬编码.

但在实践中,我倾向于硬编码一些价值观.硬编码的主要原因是:

• 根据规范,应该有这个值,不应该改变.使其可更改可能会使软件不稳定.
• 这个值可能会在以后改变,但不知道由谁和如何,所以你不知道它属于哪里.它可能属于配置文件,资源文件,数据库,注册表或其他位置.把它放在错误的地方比硬编码更糟糕.

有一些"硬编码最好的实践"我认为永远不会过度工程化:

• 硬编码值应始终在常量的中心位置声明.
• 即使值是硬编码的,它仍应作为参数传递给组件,而不必关心值的来源.它使您的组件可重用.

这使得以后可以将硬编码值移动到其他位置.