放寒假回家有些頹廢，就是不想看書。但是已經大三了，春節過后就要找實習了。哎，快樂的大學生活終于要過去了。

先從簡單的書看起吧！在圖書館借了本《The Art of Readable Code》，就是教你咋寫好優雅的代碼的，感覺還不錯。整理一下學習心得。

書中總共分了四大部分，總共15個章節。我也打算邊看邊記下筆記，用四篇文章來記錄一下學習心得。
如下：

• 第一部分：初級的一些優化
• 第二部分：簡化循環和邏輯
• 第三部分：重新組織你的代碼
• 第四部分：一些選定的主題

前戲

看原版書而不是翻譯版的有個好處就是，英文的表達很精確。

整本書始終就圍繞了一個主題來寫的

Code Should Be Easy to Understand

什么樣的代碼才算好呢？
有一個判斷的標準：縮短別人能看明白你代碼的時間。這時候估計又有同學會問了，我寫的就是給自己看的，或者團隊里就我一個人，設計到實現到測試全是我一個人，要寫給別人明白干什么？好吧，老實說，我之前也是這樣想的。“別人”不一定是其他人，也可能是三個月后的你自己。

代碼越短越好嗎？
代碼當然應該清晰易懂，這誰都知道，但是往往大牛們都不這么想。一些大牛認為代碼越短越好，在leetcode上經常可以看見這樣的話：Python One line Solution Beats 100% .確實只用了一行，但是往往讀懂它卻要用半天:(
還有三元運算符? :到底該不該用，簡單的情況下是可以使用的，比如return max == -1 ? 0 : max可以不必用if else來代替了，但是有些情況下，如果為了把代碼寫到一行中而在三元運算符中添加復雜的邏輯，以至于別人為了看懂你這行代碼，要去查一查其中運算符的優先級，那就不是好代碼了。

第一部分 ： 初級的一些優化

比如，取個好點的名字，寫上必要的注釋，格式化代碼等等，它們影響了代碼庫中的每一行代碼，雖然這些改變不破壞整體的邏輯，但是卻能使代碼更容易讀懂。

A. 在名字中包含信息

Man-Eater plant（食人花）這個名字讓人一看就懂。

1. 使用特定的單詞。比如def GetPage(url){...}這個就不夠具體，get本身有很多種意思，你到底是要干啥？替換成具體的單詞，FetchPage() DownLoadPage()都是可以的，讓人一看就明白了。
2. 避免使用通用的名字。像tmp，retval，我以前就喜歡這樣寫，為什么？還不是嫌取個名字太麻煩了，自己英文水平又不行，用拼音吧，也太low了。這種變量名字不能傳達任何信息，盡量不要用。除非在某些情況下，比如，交換兩個變量的值，這時候需要一個中間變量tmp，這個沒問題，大家都也都能看明白。多重循環的時候，也避免使用i,j,k這樣沒有任何信息的變量名，可以使用club_i, members_i, users_i這樣的，或者縮寫ci,mi,ui防止搞混淆。
3. 使用更詳細的名字。盡量詳細的將信息表達在名字中，ServerCanStart()相對于CanListenOnPort來說就很含糊。
4. 添加額外的關鍵信息。比如時間單位，開始和結束時間，start_ms end_ms后面就可以加上單位，來防止在接下來遇到其他不同單位時間的變量中出錯。
5. 為大范圍的變量起個長名字，小范圍的變量可以取個短一點的名字。如果變量只存在于一個很小的范圍中，比如只有幾行，那么map<String, int> m這樣就沒毛病。但如果map存在一個很大的范圍里面,m就不便于閱讀了。
6. 使用大寫，下劃線等去表達特定的信息。比如在C++中，類中的變量名以下劃線結尾，比如offset_，這就說明它是一個類的成員變量，而不是局部變量。

B. 名字不能模棱兩可

英語中有很多模棱兩可的單詞，比如filter，results = Database.all_objects.filter("years <= 2011")。那問題來了，results中到底是包含的<= 2012的還是not <= 2012？
表達范圍：如果要表示高低的范圍，那么加上max_和min_是很好的選擇；如果要表示兩個邊界都包含在內，那么應該用first和last；如果要左閉右開，那么應該選擇begin和end。
當命名一個布爾型變量的時候，要多使用is、has等使它表達的意思更明確。盡量不要使用負面的詞匯，比如，不應該用boolean disable_ssl = false而是用boolean use_ssl = true。
還有命名的時候要注意大家默認的習慣，比如會認為帶有get的方法是一個代價很小的輕量級的方法，但你卻用getMean()這個方法去計算了一個時間復雜度為O（n*n）的平均值，這時候就應該寫成computeMean而不是getMean。

C.在代碼中審美

這讓我想起了云棲社區之前搞的一個活動"第83行代碼"，就是大家秀一秀自己寫的代碼。反正，我看一些大牛的代碼，就感覺：哇塞！大牛就是大牛，寫代碼都感覺像是在創作，雖然看不懂寫的啥吧，但是單單從審美上就讓你震撼了。那么如何使自己代碼看起來更優雅呢？

• 如果有很多個代碼塊做的事相似，那么也給它們相同的風格，包括注釋上下對齊，保持注釋結構一致，保持代碼的對齊等等。
• 給多個變量賦值，選擇有意義的排列順序，并且始終保持這種排序。
• 將許多個聲明語句分成塊，在相應的塊上注釋好大概的功能。
• 給代碼分段，每段前寫上注釋，段與段之間一個空格隔開。
• 還有就是大括弧的問題

class Logger{
...
}
or
class Logger
{
...
}

這兩種寫法都沒問題，但要選擇一種，并且始終保持風格一致，不能混用。

D.學會去寫注釋

什么是好的注釋？有一個判斷標準：讓讀代碼的人盡可能多地知道和寫代碼的人一樣的信息。

• 當然，注釋不是什么都要地方都需要寫的。一些能直接從變量名讀出來的信息，那就不要畫蛇添足了。
• 也不要為了注釋而注釋。可能會覺得不寫注釋不妥，那就干脆寫一個注釋吧！但是注釋中其實沒有包含什么有用信息。
• 也不要為了修正代碼中糟糕的變量名來寫注釋，這時候應該直接去修改代碼，而不是在注釋中寫明。
• 注釋也斜體文本可能就是直接的記錄了你當時寫代碼的想法，這也ok。寫出來或許對讀代碼的人有幫助。
• 為代碼中的一些缺點注釋：比如

標記	意思
TODO:	我還沒抽空去解決的事
FIXME:	這里的代碼有點問題
HACK:	對于這個問題的解決方案有待改善
XXX:	危險！重災區。。

• 給自己定義的常量注釋
• 給代碼的關鍵部分，主要功能寫注釋。
• 寫總結性的注釋，讓讀者不要糾結于一些小細節之中。可以宏觀的角度看這些代碼，而不是去計較每一行。

寫注釋反正對于我是蠻難的，一方面寫的代碼不多，感覺自己注釋可能會很幼稚，一方面也覺得寫好一個注釋要花時間。看了這一章，以后寫項目代碼的時候，無論如何，也要適當的把注釋加上。

E.使自己的注釋精確、緊湊

感覺這個沒什么好說的，誰都不喜歡聽別人嘮叨：）那就從我們寫注釋開始吧！

• 避免使用它，這個，那個這樣的代詞，防止產生歧義
• 潤色一些那些“嘮叨的話”
• 闡釋你的方法的輸入、輸出時，用一些例子
• 陳述你代碼中和宏觀的意圖，而不是糾結于細節之中。
• 用一些能表達更多信息的詞，可能一個詞就能說明你原來用一句話想說明的意思。

ok！剛看完了這本書的第一部分，萬事開頭難。寒假生活開始嘍！
剩下的我會陸續更新噠~
希望對你有所幫助（￣︶￣）↗