| Beautiful is better than ugly.//優(yōu)美勝于丑陋（Python以編寫優(yōu)美的代碼為目標(biāo)）Explicit is better than implicit.//明了勝于晦澀（優(yōu)美的代碼應(yīng)當(dāng)是明了的，命名規(guī)范，風(fēng)格相似）Simple is better than complex.//簡潔勝于復(fù)雜（優(yōu)美的代碼應(yīng)當(dāng)是簡潔的，不要有復(fù)雜的內(nèi)部實現(xiàn)） Complex is better than complicated.//復(fù)雜勝于凌亂（如果復(fù)雜不可避免，那代碼間也不能有難懂的關(guān)系，要保持接口簡潔）Flat is better than nested.//扁平勝于嵌套（優(yōu)美的代碼應(yīng)當(dāng)是扁平的，不能有太多的嵌套） Sparse is better than dense.//間隔勝于緊湊（優(yōu)美的代碼有適當(dāng)?shù)拈g隔，不要奢望一行代碼解決問題） Readability counts.//可讀性很重要（優(yōu)美的代碼是可讀的） Special cases aren't special enough to break the rules.Although practicality beats purity.//即便假借特例的實用性之名，也不可違背這些規(guī)則（這些規(guī)則至高無上） Errors should never pass silently.Unless explicitly silenced.//所有錯誤都不應(yīng)該被直接忽略，除非能夠被精確的捕獲之后。（其中一個典型的例子就是，不建議用Exception:pass來直接忽略所有異常。）In the face of ambiguity, refuse the temptation to guess.//當(dāng)面對不明確的情況時，不要嘗試去猜測 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. //雖然起初這并不那么顯而易見，因為你不是 Python 之父（這里的Dutch是指Python之父Guido Van Rossum，他是荷蘭人。）Now is better than never.Although never is often better than *right* now.//現(xiàn)在行動勝過永不開始，但是不假思索就動手還不如不做（動手之前要細(xì)思量）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.//如果你的實現(xiàn)很難向別人解釋，這往往不是一個好的方案；如果你的實現(xiàn)很容易向別人解釋，這可能是個好的方案。（方案測評標(biāo)準(zhǔn)） Namespaces are one honking great idea -- let's do more of those! //命名空間是一種絕妙的理念，我們應(yīng)當(dāng)多加利用（倡導(dǎo)與號召） |
|
|
