默认值-它们是好是坏？

有关默认值的一般问题-默认返回函数值，默认参数值，缺少某些内容时的默认逻辑，用于处理异常的默认逻辑，用于处理边缘条件的默认逻辑等。

很长一段时间以来，我都认为默认值是“纯粹的邪恶”，它“掩盖了灾难”并导致非常难以发现错误。但是最近我开始考虑将默认值视为某种技术债务……这不是一件坏事，而是可以提供一些“短期融资”的东西使我们能够在项目中生存（我们中有多少人可以负担得起）在没有抵押的情况下买房？）。

当我说“短期”时，我的意思不是“首先快速地做某事，然后在它投入生产之前再进行重构”。否-我说的是在生产软件中依赖硬编码的默认值。当然-可能会导致一些问题，但是如果仅在一年内造成一次麻烦该怎么办。

再说一遍-我在这里谈论的是“平均”主流软件（不是核电站软件）-会计软件的普通网站或UI应用程序，这意味着人们的生命不会受到威胁，也不会数百万美元。

同样，根据我的经验，业务用户宁愿使用“以某种方式工作”的软件，也不愿等待完美的软件。如果您以RAD风格开发软件，则使用默认值会很有帮助。但是，我再次使用了最长的调试会话，这是因为默认值引入的错误（在此过程中不再是“默认值”），或者由于小型子系统最近已升级，因此升级并没有正确处理默认值（例如，空列表vs空，或空字符串vs空字符串）。

所以我的问题是-默认值是好是坏。而且，如果这些债务属于技术债务，该如何计算您可以借入的金额，以便您有能力偿还还款？

非常感谢您的投入。

干杯。

编辑：

如果我使用默认值作为在开发过程中偷工减料的方式-如果偷工减料会导致错误和问题-从这些问题中恢复的方法是什么？

没有合理的默认值，“约定高于配置”的概念是不可能的。这里的关键词是“明智的”。对于库/服务/框架的所有使用，默认值必须至少占80％（如果不是更多）。

一般经验法则：

• 如果合理使用80％或更高的值，则该值为默认值
• 如果没有大多数情况下使用的值，请不要使用默认值。
• 默认值可防止设置代码中出现愚蠢的错误。如果默认设置在大多数情况下是合理的，则更少的人会干扰正常的配置。
• 使用默认设置时，非标准配置更加明显。
• 错误的默认设置比没有默认设置更糟糕。

本质上，一旦您了解了默认配置的工作原理，就可以就如何/何时进行非标准配置做出明智的决定。

以实现FTP协议的库为例。默认情况下，FTP应该在端口21上运行。现在，如果每次构造随机FTP类的对象时都必须指定使用端口21，我会感到非常恼火。如果需要其他端口，请指定。

当默认值是理智的默认值时，它们就很好。

您可能正在使用默认键盘布局，默认键映射，默认鼠标按钮映射，默认浏览器，键入系统默认语言，从引导加载程序中的默认OS引导，默认定位的菜单，默认配色方案，默认字体宽度/高度/面部/样式，默认字符集，默认显示器分辨率，默认值...您就会明白。

但实际上，我认为您所担心的不是默认值，而是其他。默认行为不会天生掩盖错误。无论您是否设置默认值，大多数时候代码无论如何都会在常见条件下运行。未处理的极端情况是您要确保避免更改（默认情况下是通过适当的适当测试）的情况，以防止更改默认值或发生不常见的情况。

同样，“包罗万象”的异常处理可以说是设计缺陷，而不是您可以称之为“默认”的任何东西。

当它们使用户或开发人员免于执行重复性任务时，应使用默认值。绝对不要使用它们来掩盖错误或异常。使用它们来防止错误不是一个坏习惯，但前提是该预防措施不能掩盖不良情况。就像其他所有内容一样，默认值是一种工具。正确使用它们可以为您节省很多头痛和时间。使用不当会导致整座房屋倒塌。

您提到的问题的根本原因不是默认值本身，而是由于更改接口协定，解释误解和/或无效假设导致的集成问题。基本上，所有这些（特定示例）似乎都是由于客户与开发人员之间或不同的开发人员/团队之间进行不正确沟通所导致的。公平地说，这些问题可能表现为无效的默认值，但也可能以其他无数形式出现。

处理根本原因，而不是症状。

还要注意，正如其他人以出色的例子所指出的那样，默认值在明智地使用时可以大大简化用户的生活。这最终是我们的目标，不是吗？

不属于通信协议/约定的默认值是有害的。所谓“不是一部分”，是指在协议严格的地方没有记录它们，或者在协议松散的地方根本没有期望它们。

如果记录/期望了默认值，那么它仍然可以是邪恶的，但也可以确保生命安全。这取决于域区域。很多时候它们很危险（例如默认的药物剂量，默认的电梯楼层，默认的轿厢移动方向），有时没有它们（例如默认的轿厢移动方向，默认的开会时间）可能很危险。