编码的道与禅

Bob 大叔在《代码整洁之道》一书的前言打趣着说，当你写的代码在经受代码审查时，如果审查者愤怒的吼道“What the fuck is this shit?”等言辞激烈的词语时，那说明你写的是 Bad Code；如果审查者只是漫不经心的吐出几个“What the fuck?”，那说明你写的是 Good Code。这就是衡量代码质量的唯一标准——每分钟骂出“What the fuck?”的频率。

想写出整洁的代码很难，有一部分原因在于糟糕的代码太容易编写。想快点完成任务时，考虑不周全时，忽略安全时，随意命名时，参数过多时，嵌套太深时，未及时更改注释时，违反法则时，重复你自己时等等情形，我们有太多的机会来制造糟糕的代码。只有严肃对待自己的代码，了解哪些事情会使我们的代码变味，才有可能写出整洁的代码。

写代码和写文章在某种程度上有相似之处，好的文章一定有好的可读性，写代码也一样，只有优美干净的代码才能具有良好的可读性。编写具有可读性的代码不光是保持有意义的命名就行，如果你想成为一名更好的程序员，写代码时你需要注意的有很多，比如：

1. 规范本地变量的位置
2. 使函数尽量短小
3. 调用者尽可能放在被调用者上面
4. 保持代码拥有良好的格式
5. 编写只做一件事的函数
6. 函数参数不要超过三个
7. 暴露时序耦合
8. 使用异常代替返回错误码

除此之外，你还须牢记众多设计原则，如：

1. 开放封闭原则（OCP）
2. 迪米特法则
3. 依赖倒置原则（DIP）
4. 单一职责原则（SRP）
5. 里氏替换原则（LSP）
6. 不要重复（DRY）
7. 你不会需要它（YAGNI）

当然仅有这些是不够的，这不是骑自行车，学写整洁代码得花许多功夫，必须不断实践，从失败中提取代码的坏味道并从中得到启发。

编写整洁代码，你需要牢记并遵守很多东西，但这并不是循规蹈矩和刻板，而是对简单之美、代码之美的追求。代码整洁之道，是编写优秀代码的一种方法，其核心是尽力使代码保持简单——Keep It Simple, Stupid。判断一个人写的代码的好坏，不是看它的代码写的有多复杂，而是看他有没有把复杂的事物抽象出来并用简单的方式去描述它，此外这个人对代码的态度也至关重要，大多数时候我们并不能从一开始就把代码写的很完美，当我们需要快速做出一个原型，或者一开始代码看起来不错，但新的需求使现有的设计无法满足，如果不对设计进行改动的话，那么代码就会变的丑陋，如果你热爱自己正在做的事情，崇尚代码之美，那么你就会有足够的动力去重构它、完善它，而不是破坏结构使代码腐烂。

保持简单、追求简单，我想这就是编码之中的禅意，一种追求本真的境界。这种禅在 Python 的设计哲学中体现的淋漓尽致，让我们在 Python 解释器中输入“import this”，来看看经典的 Python 之禅。

• Beautiful is better than ugly.
  优美胜于丑陋。
• Explicit is better than implicit.
  显式胜于隐式。
• Simple is better than complex.
  简单胜于复杂。
• Complex is better than complicated.
  复杂胜于难懂。
• Flat is better than nested.
  扁平胜于嵌套。
• Sparse is better than dense.
  分散胜于密集。
• Readability counts.
  可读性应当被重视。
• Special cases aren’t special enough to break the rules. Although practicality beats purity.
  尽管实用性会打败纯粹性，特例也不能凌驾于规则之上。
• Errors should never pass silently. Unless explicitly silenced.
  除非明确地使其沉默，错误永远不应该默默地溜走。
• In the face of ambiguity, refuse the temptation to guess.
  面对不明确的定义，拒绝猜测的诱惑。
• There should be one– and preferably only one –obvious way to do it.
  用一种方法，最好只有一种方法来做一件事。
• Although that way way not be obvious at first unless you’re Dutch.
  虽然一开始这种方法并不是显而易见的，但谁叫你不是Python之父呢。
• Now is better than never. Although never is often better than right now.
  做比不做好，但立马去做有时还不如不做。
• If the implementation is hard to explain, it’s a bad idea.
  如果实现很难说明，那它是个坏想法。
• If the implementation is easy to explain, it may be a good idea.
  如果实现容易解释，那它有可能是个好想法。
• Namespaces are one honking great idea – let’s do more of those!
  命名空间是个绝妙的想法，让我们多多地使用它们吧！

道着重于方法，禅着重于态度，让我们把这两者相结合，做一个有追求的程序员，为成为软件匠人而奋斗吧。

原文链接：https://github.com/lcomplete/...