對(duì)待代碼，就像對(duì)待情人，要用心，要寫得大方，優(yōu)雅。曾有人用代碼量來評(píng)估編程水平，純屬扯淡。如果你的代碼，能讓普通人都看得懂，那必然是好的代碼，如果你的代碼給同行人帶來迷惑，那你該為自己感到羞愧！廢話一堆，見正文。

>>> import this
The Zen of Python, by Tim Peters
/*美的要比丑好，好實(shí)在的廢話，抽象到不用解釋！*/
Beautiful is better than ugly.
/*代碼要像做人一樣，不要那么多騷套路，簡(jiǎn)單點(diǎn)，寫代碼的姿勢(shì)簡(jiǎn)單點(diǎn)。
遵循規(guī)范，自己舒服，別人也舒服。*/
Explicit is better than implicit.
/*代碼邏輯要清晰簡(jiǎn)單，用人的角度想問題，順理成章的寫，不要簡(jiǎn)單問題復(fù)雜化。*/
Simple is better than complex.
/*好吧，如果問題確實(shí)挺復(fù)雜，那也要寫得清晰，不能凌亂到自己都抗拒回看*/
Complex is better than complicated.
/*嵌套真的會(huì)加大閱讀難度，咱能惡心計(jì)算機(jī)，咱不能惡心人呀*/
Flat is better than nested.
/*你要壓縮代碼嗎？你是不想讓別人看嗎？你是覺得多點(diǎn)代碼，會(huì)加大你的電腦負(fù)擔(dān)嗎？
不是的話，請(qǐng)把變量名縮寫改回來，請(qǐng)把該有的縮進(jìn)加回來，如果你的一
行代碼很難閱讀，改成三行吧。*/
Sparse is better than dense.
/*伙計(jì)代碼可讀性老重要了，盡管你的具體實(shí)現(xiàn)好復(fù)雜，也不能打破上面的規(guī)則，
別騙自己啦，其實(shí)你可以寫的更好的。*/
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
/*應(yīng)該精確控制每一個(gè)錯(cuò)誤，不至于當(dāng)錯(cuò)誤爆發(fā)時(shí)，你竟然方了，這什么鬼？
如果你不想讓程序報(bào)錯(cuò)，就把程序?qū)懙慕腰c(diǎn)。*/
Errors should never pass silently.
Unless explicitly silenced.
/*面對(duì)分歧，不要瞎猜，應(yīng)該試圖找唯一一種最合理的方式去解決他，
要理性思考，理性分析。雖然這挺難，但是也要這么做。*/
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 may not be obvious at first unless you're Dutch.
/*如果你覺得做某事太遲了，那現(xiàn)在就是做此事最早的時(shí)刻，勵(lì)志到好像不是在講代碼了。*/
Now is better than never.
/*當(dāng)然，客觀講，你如果走錯(cuò)了方向，那還不如老實(shí)待在原點(diǎn)呢，所以要多思考呀，別走反了路子。
不過個(gè)人認(rèn)為，走點(diǎn)反路也沒啥，走了反路，才更明白正確的路該怎么走，只是別老走冤枉路啊。*/
Although never is often better than *right* now.
/*如果你的實(shí)現(xiàn)方式，你自己都覺得不太合理，那還是別出來丟人了。
你應(yīng)該為你寫的東西感到自豪。*/
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.
/*命名空間真是個(gè)好的理念，大家都來用呀。啥叫命名空間呀？不就是一個(gè)大包包里面，
裝了好多小包包，小包包里面又有好多小包包，小包包里面又有小包包。。。大神都講了，
萬物皆對(duì)象呀，自然萬事都既是大包包也是小包包了！*/
Namespaces are one honking great idea -- let's do more of those!