《修改代碼的藝術》讀書筆記二

此次總結一下寫代碼應當注意的一些細節問題：

代碼應當易於理解

• 代碼的寫法，應當便於別人理解它須要的時間最小化

把信息裝入名字中

• 選擇專業的詞，避免使用空洞的詞
• 找到更有表現力的詞
• 避免像tmp這樣的範範的名字
• 像i、j等名字經常使用作索引或者迭代器，儘管空泛，可是你們都知道他的意思

用具體的名字代替抽象的名字

• 使用具體的名字來更細緻的描述事物
• 給變量帶上更重要的細節（例如在值爲毫秒的變量後面加上_ms）
• 爲做用域大的名字採用更長的名字，不要用讓人費解的一個或者兩個字母的名字來命名幾屏之間均可見的變量
• 有目的的使用大小寫和下劃線等

使用不會被誤解的名字

• 推薦用min和max來表示極限的狀況
• 推薦使用first和last來表示包含的範圍
• 推薦用begin和end來表示包含和排除範圍
• 給boolean值命名加上is、has、can會更加易於理解
• boolean 這一類，避免使用反義名詞（例如disable_ssl=false不如use_ssl=true）

代碼的審美

• 使用一直的佈局，讓讀者很快就能習慣這種風格
• 讓類似的代碼看上去類似
• 把相關的代碼進行分組，造成代碼塊
• 從新安排換行來保持一致和緊湊（例如構造函數中多個參數）
• 用方法來整理不規則的東西
• 在須要的時候使用列對齊
• 把代碼按照業務含義分紅「段落」
• 我的風格的一致性
• 一致的風格比「正確」的風格更重要

什麼狀況不須要註釋

• 不要爲了那些從代碼自己就能快速推斷的事實寫註釋
• 不要爲了註釋而註釋
• 不要給很差的名字加註釋，應該把名字改好

用註釋記錄你的思想

• 對於爲何代碼寫成這樣而不是那樣的內在理由
• 代碼中的缺陷，使用TODO或者XXX來進行標記
• 常量背後的故事，爲何是這個值

站在讀者的立場上思考

• 預料到代碼中哪些部分會讓讀者不理解，這時候須要添加註釋了
• 爲普通讀者意料以外的行爲加上註釋
• 在文件或者類級別上使用全局觀的註釋來解釋
• 用註釋來總結代碼塊，是讀者不致於迷失在細節中

把控制流變得易讀

• 條件語句的參數順序（比較的右側，用來比較的表達式，更加傾向於常量）
• if/else中，首先處理正邏輯而不是負邏輯，優先處理簡單的狀況，先處理有趣或者可疑的狀況
• 默認狀況下使用if來進行判斷，三目運算符在最簡單的狀況下使用
• 避免使用do/while循環，由於while循環相對更加易讀，先條件後代碼塊
• 嵌套的代碼塊須要更加集中精力去理解，每層新的嵌套都須要讀者把更多的上下文信息帶入，應該把他們改爲更加線性的代碼來避免深嵌套
• 一般來說，提前返回能夠減小嵌套並讓代碼整潔

拆分超長的表達式

• 一個簡單的技術是引入「解釋變量」來表明較長的子表達式，這樣能夠把巨長的表達式拆成小段，讀者更加容易理解代碼中的主要概念
• 德摩根定律來操做邏輯表達式（例如if(!(a && !b))）改成 if(!a || b)

變量與可讀性

• 減小變量，消除沒用的「中間結果」
• 減小每一個變量的做用域，越小越好
• 只寫一次的變量更好

從新組織代碼

• 把通常的代碼和項目專有的代碼分開
• 組織代碼的簡單技巧，一次只能作一件事情
• 用天然語言描述程序，而後用這個描述來幫助你寫出更加天然的代碼

少寫代碼

• 從項目中消除沒必要要的功能，不要過分設計
• 常常性的通讀標準庫的整個API，保持對他們的熟悉程度