#10.1 什么应是可配置的

对于问题：什么应是可配置的？
无畏的 Unix 回答是“一切”。Unix 程序员只要可能，就建立机制而把策略决定权交给用户。这种方式产生的程序往往功能强大，专家用户用起来会非常顺手。但它所产生的接口往往选项过多，并且配置文件像杂草一样疯长，从而彻底打击了新手和一般用户。

Unix 并不打算修改这种为同行和最老练用户设计的倾向。所以，也许把问题反过来，问问“什么不应该可配置”更加有用。Unix 实践的确在这方面提供了一些指导。

对于能够可靠的进行自动检测的东西，就不要提供配置开关。
- 应当尽量用自动检测来减少配置开关的数量，或者在运行时不断尝试直到成功。如果觉得这个方法不够优雅或太昂贵，问问自己是不是掉进了过早优化的陷阱。
- 一个很好的经验法则是：提高适应能力，除非这样做会产生超过 0.7 秒的延迟。0.7 秒是一个魔数，因为，正如 Jef Raskin 设计 Canon Cat 计算机时的发现，人们几乎觉察不到少于 0.7 秒的启动延时;人们还没有来得及转移注意力，它就消失了。
用户不应该看到优化开关。让程序经济运行是设计者的任务，不是用户的任务。
- 与提高界面复杂度成本相比，让用户从优化开关来获取的那点儿性能收益，换来界面复杂度的提升，往往得不偿失。
能简单利用其它程序来完成的任务，就不要增加本程序的复杂度。

无论何时想增加配置选项，请考虑以下这些较普遍的问题：

为函数增加形参时，也可以自问上述问题

增加不必要的选项会产生诸多不良后果。其中最不易察觉但最严重的后果是对测试覆盖率的影响。

除非做得非常仔细，否则增加一个开/关配置选项就会使测试量加倍。既然在实践中从来没有人完成双倍测试量，那么实际影响就是减少了特定配置获得的测试量。增加十个选项会产生 1024 倍测试量，所以不要多久就要讨论可靠性问题了。
—— Steve Johnson

#10.5 命令行选项

原始的 Unix 传统中，对于命令行选项偏爱小写字符而不是大写字符。

约定都不是绝对的，但是违反这些约定会增加用户和未来开发者的磨合成本。