读代码整洁之道

发表于

引子：

写了好几年的代码了。其中也养成了很多从学生时期一路带过来的坏习惯。最近也是翻开了《代码整洁之道》这本书，希望能帮助自己在代码风格上有所提高，慢慢改掉不好的代码习惯。

一.原则：

童子军军规：让营地比你来时更干净。

对应之为：每一次代码的迁出要比迁入之前干净。

书中开篇便引用了工业生产中为了保证产品质量而使用的TPM(Total Productive Maintenance)手段，其中支撑体系为5S原则体系：

整理(Seiri),整顿(Seiton),清楚(Seiso),清洁(Seiketsu),身美(Shitsuke)

这套原则也同样适用于软件开发的过程之中。

二.关于对整洁代码的理解：

我喜欢优雅和高效的代码。代码逻辑应该直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省的引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。——Bjarne Stroustrup

整洁的代码简单直接。整洁的代码如同优美的散文，整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。 —— Grady Booch

… … 消除重复和提高表达力让我在整洁代码方面获益良多，只要铭记这两点，改进脏代码时就会大有不同。—— Ron Jeffries

三.关于变量命名：

《代码整洁之道》书中第一篇就说关于命名的问题。

关于命名的原则：

  1. 方法和函数名要有意义。尽量不要在变量中带入数据的类型，使用a1,a2这种第二天就看不懂的命名更是不可取。（这里其实也有异议，在我看来像java这样的强类型语言当然是正确的做法，但是在js中，反映出类型的变量却更方便维护）
1
2
3
4
var userList = [];   // 不好

var users = [];
var userGroup = [];  // 好
  1. 减少可能引起误会的命名，如大写的I和容易和1混淆，大写的O容易和0混淆等。
  2. 减少可能会误导开发者的命名，如：
1
2
3
function getActiveAccount(){}
function getActiveAccounts(){}
function getActiveAccoutInfo(){}

以上的三个方法你很难从字面去区别其异同。

4.减少命名中的废话，如：

1
2
var nameString = 'Liudehua';  // name 就不可能是int类型
var variableTest = '112';     // variable 就不该出现在变量命名中

5.类名尽量使用名词和形容词，方法名则是使用动词。

1
2
3

class Person{}  // 常见的类名,Person为名词
Person.run()    // run为动词，作为方法名

6.适当的根据语义以及环境使用前缀。

四.关于函数

1.精简，短小，尽量不要有超过一屏的函数出现。

2.每个函数只能做一件事。

3.函数要么做什么事，要么回答什么事，但二者不可得兼。

4.重复可能是软件中一切邪恶的根源。许多的原则与实践规则都是为了控制与消除重复而创建的。

5.没人一开始就能写出完美的函数，需要自己打磨这些代码，分解函数，修改名称，消除重复。

6.函数是动词，类是名词。编程艺术是且一直是语言设计的艺术。

五.关于注释

1.注释的用法是为了弥补我们在用代码表达意图时遭遇的失败。

2.注释的存在时间越长，就离其所描述的代码越远，越来越变得全然错误。

3.不准确的注释要比没注释坏得多。

他们满口胡言。他们预期的东西永远不能实现。他们设定了无需也不应该遵循的就规则

4.注释并不能美化糟糕的代码。

小结

代码整洁之道这本书很厚，就代码书写的风格层面来说，我比较认可上述的几个观点。书中还有关于语言层面更为详尽的编码建议，例如错误处理，类的设计等等，但是这些都和具体的开发语言相关联了，不作为通用性的参考，我就没有一一描述。这里有一个观点很重要，就是 程序员的代码首先是给人来阅读的，其次才是给机器去执行，所以说写让人易于阅读和维护的代码，在一定程度上比追求极致的内存和性能的利用要重要。