The Zen of GitHub

The Zen of Python

1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one-- and preferably only one --obvious way to do it.
14. Although that way may not be obvious at first unless you're Dutch.
15. Now is better than never.
16. Although never is often better than *right* now.
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea -- let's do more of those!

体裁源头。GitHub 那份的 "Practicality beats purity" 是整句搬过来的。这里有两个细节值得注意:第 14 条 "unless you're Dutch" 是在开 Guido van Rossum 的玩笑(荷兰人),说明作者自己都没把它当法典;PEP 20 正文只有 19 条,而文档里说有 20 条——第 20 条留白,官方从未补上。Tim Peters 本人说这是半开玩笑写的。

The Zen of Go

1. Each package fulfils a single purpose 每个包只服务一个目的
2. Handle errors explicitly 显式处理错误
3. Return early rather than nesting deeply 尽早返回,别深层嵌套
4. Leave concurrency to the caller 把并发的决定权留给调用方
5. Before you launch a goroutine, know when it will stop 起 goroutine 前先知道它何时停
6. Avoid package level state 避免包级状态
7. Simplicity matters 简单性很重要
8. Write tests to lock in the behaviour of your package's API 用测试锁住 API 的行为
9. If you think it's slow, first prove it with a benchmark 觉得慢,先用 benchmark 证明
10. Moderation is a virtue 节制是一种美德
11. Maintainability counts 可维护性很重要

最像"规范"的一份,也因此最不像禅。它明确讨论 goroutine、package、benchmark 这些具体机制,可执行性最强,但也最容易过期——语言一变,第 6 条第 4 条就要重写。相比之下 GitHub 那 14 条十几年不用改,代价是它不告诉你怎么做。抽象度和保质期是一对交换。

The Rails Doctrine

1. Optimize for programmer happiness 为程序员的幸福感优化
2. Convention over Configuration 约定优于配置
3. The menu is omakase 菜单是主厨定的(全家桶,别单点)
4. No one paradigm 不奉行单一范式
5. Exalt beautiful code 推崇漂亮的代码
6. Provide sharp knives 提供锋利的刀(不为防呆而阉割)
7. Value integrated systems 看重一体化系统
8. Progress over stability 进步优先于稳定
9. Push up a big tent 搭一个大帐篷(容纳分歧)

严格说这不是箴言体,是宣言体。每条背后都有一整篇长论述,读起来是"为什么我们这样选",而不是"你该这样做"。它是解释性的,Zen 是断言性的。第 3 条 omakase 和第 6 条 sharp knives 尤其能看出差别——这两句离开上下文根本无法引用,而 "Speak like a human" 可以裸着扔进任何一场争论。

The Unix Philosophy

McIlroy 原文四条:(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. (ii) Expect the output of every program to become the input to another, as yet unknown, program. (iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. (iv) Use tools in preference to unskilled help to lighten a programming task.

• Write programs that do one thing and do it well. 一个程序只做一件事,做好
• Write programs to work together. 程序之间要能协作
• Write programs to handle text streams, because that is a universal interface. 用文本流,因为它是通用接口

它跟前三份不是一个物种。Zen of X 是内部人写给自己人的规范性文本("应该这样");Unix philosophy 是事后对一个已经成功的系统做的描述性总结("它之所以成,是因为这样")。同族的还有 Conway's Law、Postel's Law、Rule of Least Power——都是单条、外部视角、可证伪。
把它们混着引用的典型翻车:拿 Postel's Law("接收时宽容")当设计准则,结果做出一个谁都猜不透行为的 API——而它原本只是对 TCP/IP 为什么能活下来的一句观察。