2.2 正确、简单和清晰第一
摘要
软件简单为美（Keep It Simple Software，KISS）：质量优于速度，简单优于复杂，清晰优于机巧，安全优于不安全（见第83条和第99条）。
讨论
简单设计和清晰代码的价值怎么强调都不过分。代码的维护者将因为你编写的代码容易理解而感谢你——而且这个维护者往往就是未来的你，要努力回忆起6个月前的所思所想。于是有了下面这些经典的格言警句。
程序必须为阅读它的人而编写，只是顺便用于机器执行。——Harold Abelson 和 Gerald Jay Sussman
编写程序应该以人为本，计算机第二。——Steve McConnell
计算机系统中最便宜、最快速、最可靠的组件还不曾出现过。——Gordon Bell[2]
所缺乏的恰恰是最精确（永不出错），最安全（坚不可摧），以及设计、文档编写、测试和维护起来最容易的部分。简单设计的重要性怎么强调也不过分。——Jon Bentley
本书中的许多条款都能够自然地产生易于修改的设计和代码，而清晰性是易于维护、易于重构的程序最必需的特征。自己不能充分理解的设计和代码，就更无法充满自信地进行修改了。
这里最常见的紧张关系恐怕就在代码清晰和代码优化（见第7条、第8条和第9条）之间。当（不是假如）你想为了性能而进行不成熟的优化因而影响了清晰性时，请回想一下第8条的要点：使一个正确的程序变快，比使一个快速的程序正确要容易得多。
要避免使用程序设计语言中的冷僻特性。应该使用最简单的有效技术。
示例
例1 不要使用不必要的或者小聪明式的操作符重载。有一个毫无必要古怪的图形用户界面库，竟然允许用户编写w+c;这样的语句表示在图形组件w上添加子控件c。（见第26条。）
例2 应该使用命名变量，而不要使用临时变量，作为构造函数的参数。这能够避免可能的声明二义性。这还经常能使代码的意图更加清晰，从而更容易维护，而且通常也更安全（见第13条和第31条）。
参考文献
[Abelson96] ● [Bentley00] §4 ● [Cargill92] pp.91-93 ● [Cline99] §3.05-06 ● [Constantine95] §29 ● [Keffer95]p.17 ● [Lakos96] §9.1, §10.2.4 ● [McConnell93] ● [Meyers01] §47 ● [Stroustrup00] §1.7, §2.1, §6.2.3, §23.4.2, §23.4.3.2 ● [Sutter00] §40-41, §46 ● [Sutter04] §29