1700490519
大脑非常善于在模型片段的基础上重构事实。大脑也能基于不完整的数据进行联想，它一直都在这样做，即使你并没有意识到。
1700490520
1700490521
4.5.1 代码中的模式
1700490522
1700490523
这里举一个模式的例子，如果你是程序员的话可能曾经遇到过。源代码，即使是使用等宽字体，也具有一些版面上的特性，有助于读者理解编写者的意图。
1700490524
1700490525
代码，一次编写，多次阅读。
1700490526
1700490527
Code is write-once, read-many.
1700490528
1700490529
请记住，源代码的阅读次数远远多于它的编写次数，所以通常值得花一些工夫把代码变得适合人类阅读。换句话说，我们应该使代码中的较大模式更容易被看到。
1700490530
1700490531
例如，为什么我们要使用等宽字体？编译器并不在意这些。但是我们往往愿意对齐文字、括号和代码：
1700490532
1700490533
String foofoo=10
1700490534
1700490535
int bar = 5
1700490536
1700490537
使它们便于浏览和识别。同样，你往往会通过字符图形分割代码块，如：
1700490538
1700490539
1700490540
1700490541
1700490542
这会吸引你的注意力，而且，如果做得有规律，这还会组成你大脑中识别和理解的一个较大模式。读者Dierk Koenig告诉我们他主动花时间以这种方式来“排版”他写的代码。
1700490543
1700490544
新手会立刻开始这样做——毕竟，这是一种很容易遵循的规则。但是高级初学者可能会拒绝，抱怨花时间在代码格式上是一种浪费。精通者和专家则会对格式差的代码发怒，如果难以看到那些他们早已习惯要看见的模式，不论写的代码是什么，他们都会认为很糟糕。
1700490545
1700490546
这些视觉提示有很多形式，比如对齐格式和头部说明块，还包括更细致的形式如方法的大小。一旦你习惯了阅读只有几行代码的小方法，遇到一个非常长的方法你就会认为是错的。
1700490547
1700490548
括号的放置也形成了一种可视化的模式，这也是为什么有人长期执着地争论，一定要坚持在那些使用花括号的语言中遵守一种特定形式的括号位置。他们不是为了争论而争论，而是因为模式匹配影响他们的感知。
1700490549
1700490550
然而，代码中的模式匹配也有不好的一面。看看下面这个用可敬的C语言所编写的经典代码片段：
1700490551
1700490552
if (receivedHeartbeat())
1700490553
1700490554
resetWatchdog();
1700490555
1700490556
else
1700490557
1700490558
notifyPresident();
1700490559
1700490560
launchNukes();
1700490561
1700490562
在这个令人遗憾的例子中，不论receivedHeartbeat（）的值是多少，launchNukes（）总是会被执行。缩进的代码看起来很舒服，可读性强，但是编译器并不这样认为：else只关联了第一个语句，缩进反而起了误导的作用。排版对感知具有很强的影响——无论是好还是坏。
1700490563
1700490564
适应不同技能层次。
1700490565
1700490566
Accommodate different skill levels.
1700490567
1700490568
请努力使用一致的排版提示来辅助可视化知觉。编译器也许不在意，但是我们的确在意。对下述可能会出现的情况也要理解：如果你处于较高的技术水平上，同时又遭遇到团队里其他人的阻力，要明白他们看待问题的方式肯定和你不同。他们不会自觉地认识到这种价值，因此你必须向他们解释。