h8

Clean Code

最近买的一本书 (Amazon)。只读了前面一点,书没有想象中的好。

第一章以几乎偏执的态度强调代码风格的重要性。但是从第二章来看,很多地方我都和作者的观点不尽相同。

比如说,我不觉的函数体总是越短越好。因为一段代码的可读性并不总是和函数长短相关。一个复杂的程序里如果都写成两三行的函数并不好读,很可能会把本来可以用缩进很清晰就可以表示出来的决策树,拆分成一堆四散的碎片,把一幅一体的图像扭曲成一个迷宫。同时,也会给代码读者增加大量记背函数名称的负担。更好的标准应该是,每个函数应该代表同一层面的抽象,并且抽象的复杂度能正好在一个普通人类的认知水平之内,不太多也不太少。如果函数太长以至于在一个普通人类的大脑中一般装不下了,那么这个函数应该拆一下。如果函数里有两层或两层以上的抽象,明显上一层依赖于下一层,那么下一层的抽象应该有个名字,成为一个独立的函数,单拿出来。函数调用的层次应该符合模型抽象的层次。这本质是个建模问题,是个层次大小和层次多少之间的trade-off。函数体并不是越小越好,而是模型要长宽高比较简约方正而容易认知才是最好的。

再比如说,我从来不觉的变量名应该很长。相反,我经常觉得变量名应该适中而简短,这样才能一眼看清程序的符号结构。一个程序的符号结构往往比变量名的语义会给读者带来更多的信息。变量名太长其实往往是模型混乱,不必要的模型抽象太多的结果。用程序结构本身能清晰表示的逻辑,不应该引入多余的名称和概念来冗长地解释。一幅清晰缩进的代码图画,肯定是胜过一堆变量名堆成的文字的。

另外,书语言的风格太偏执了。论断太多,但是事实其实举的很少,所以不是很有说服力。总的来说,可能适合初学者确立一个严谨的代码态度,但是对代码风格的探讨细节上其实并不是很靠谱。