該文章釋出在github中，如果您覺得寫的還不錯的話，可以 star 一下進行支援，傳送門：TechShare。
Bob 大叔在《程式碼整潔之道》一書的前言打趣著說，當你寫的程式碼在經受程式碼審查時，如果審查者憤怒的吼道“What the fuck is this shit?”等言辭激烈的詞語時，那說明你寫的是 Bad Code；如果審查者只是漫不經心的吐出幾個“What the fuck?”，那說明你寫的是 Good Code。這就是衡量程式碼質量的唯一標準——每分鐘罵出“What the fuck?”的頻率。
想寫出整潔的程式碼很難，有一部分原因在於糟糕的程式碼太容易編寫。想快點完成任務時，考慮不周全時，忽略安全時，隨意命名時，引數過多時，巢狀太深時，未及時更改註釋時，違反法則時，重複你自己時等等情形，我們有太多的機會來製造糟糕的程式碼。只有嚴肅對待自己的程式碼，瞭解哪些事情會使我們的程式碼變味，才有可能寫出整潔的程式碼。
寫程式碼和寫文章在某種程度上有相似之處，好的文章一定有好的可讀性，寫程式碼也一樣，只有優美乾淨的程式碼才能具有良好的可讀性。編寫具有可讀性的程式碼不光是保持有意義的命名就行，如果你想成為一名更好的程式設計師，寫程式碼時你需要注意的有很多，比如：
- 規範本地變數的位置
- 使函式儘量短小
- 呼叫者儘可能放在被呼叫者上面
- 保持程式碼擁有良好的格式
- 編寫只做一件事的函式
- 函式引數不要超過三個
- 暴露時序耦合
- 使用異常代替返回錯誤碼
除此之外，你還須牢記眾多設計原則，如：
- 開放封閉原則（OCP）
- 迪米特法則
- 依賴倒置原則（DIP）
- 單一職責原則（SRP）
- 里氏替換原則（LSP）
- 不要重複（DRY）
- 你不會需要它（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!
名稱空間是個絕妙的想法，讓我們多多地使用它們吧！
道著重於方法，禪著重於態度，讓我們把這兩者相結合，做一個有追求的程式設計師，為成為軟體匠人而奮鬥吧。