# 易讀 ### 簡介 ### 無關的編程經驗 > 只要我有更多時間，我就會寫一封更短的信給你。 從小學算起我的編程年限應該也有十幾年了吧，笑~~。只是我過去的多年編程經驗對于我現在的工作來說，是多年的無關經驗(詳見《REWORK》——多年的無關經驗)。 高中的時候學習了點游戲編程，也因此學了點C++的皮毛，除了學會面向對象，其他都忘光了。隨后在學習Linux內核，當時代碼里就各種struct。比起之前學過的Logo和QBASIC簡直是特別大的進步，然當時覺得struct與面向對象兩者間沒啥太大區別。在那個年少的時候，便天真的以為程序語言間的區別不是很大。 大學的時候主要營業范圍是各種硬件，也沒有發現寫出好的代碼是特別重要的一件事。也試了試Lisp，嘗試過設計模式，然后失敗了，GoF寫DP的時候一定花了特別長的時間，所以這本書很短。期間出于生活壓力(沒有錢買硬件)，便開始兼職各種Web前端開發。 在有了所謂的GNU/Linux系統編譯經驗、寫過各種雜七雜八的硬件代碼，如Ada、匯編，要保證代碼工作是一件很簡單的事，從某個項目中引入部分代碼，再從某個Demo中引入更多的代碼，東拼西湊一下就能工作了。 多年的無關經驗只讓我寫出能工作的代碼——在別人看來就是很爛的代碼。于是，雖然有著看上去很長的編程經驗，但是卻比不上實習的時候6個月學到的東西。 只是因為，我們不知道: 我們不知道。 ### 代碼整潔 過去，我有過在不同的場合吐槽別人的代碼寫得爛。而我寫的僅僅是比別人好一點而已——而不是好很多。 然而這是一件很難的事，人們對于同一件事物未來的考慮都是不一樣的。同樣的代碼在相同的情景下，不同的人會有不同的設計模式。同樣的代碼在不同的情景下，同樣的人會有不同的設計模式。在這里，我們沒有辦法討論設計模式，也不需要討論。 我們所需要做的是，確保我們的代碼易讀、易測試，看上去這樣就夠了，然而這也是挺復雜的一件事: 1. 確保我們的變量名、函數名是易讀的 1. 沒有復雜的邏輯判斷 1. 沒有多層嵌套 1. 減少復雜函數的出現 然后，你要去測試它。這樣你就知道需要什么，實際上要做到這些也不是一些難事。 只是首先，我們要知道我們要自己需要這些。 ### 別人的代碼很爛? 什么是很爛的代碼? 應該會有幾種境界吧。 1. 不能工作，不能讀懂 1. 不能工作，能讀懂 1. 能工作，很難讀懂 1. 能工作，能讀懂，但是沒有意圖 1. 能工作，能理解意圖，但是讀不懂 如果我們能讀懂，能理解意圖，那么我們還說他爛，可能是因為他并不整潔。這就回到了上面的問題，模式是一種因人而異的東西。 我們在做Code Review的時候，總會嘗試問對方說： “這樣做的意圖是”。 對于代碼來說也是如此，如果我們能理解意圖的話，那么我們要理解代碼相對也比較容易。如果對方是沒有意圖，那么代碼是沒救的。 ### 變量名 ### 函數名 ### 小函數 ### 測試