程式碼整潔之道-閱讀筆記
一段時間的專案忙碌之後，對工作和業務都有了一定層次的瞭解。經過自己的思考與別人的指導，也能夠區分出什麼樣的程式碼是好程式碼和垃圾程式碼，是時候看些理論書籍來鞏固下自己的這些理解。當然這樣經典的書，讀一遍肯定是不夠的，期待以後具備更佳的能力和見識的再讀此書，能有另一番思考與體會。
導語
個人覺得程式碼的整潔程度是非常能夠體現一個人的做事態度的特徵之一。畢竟聞道有先後，初入職場或者初入程式設計行業的人，沒有老司機那麼有架構、模組、設計模式之類的經驗。而寫出乾淨、簡潔、明瞭的函式和類，就應當成為一開始寫程式碼的人追求的目標。我們寫出良好的程式碼，第一為了自己之後能夠方便回溯，第二為了給別人減少麻煩。–下面即開始我的閱讀《程式碼整潔之道》的第一次筆記。
有意義的命名
這一章節比較簡單。總結出來就是無論是變數名稱、方法名稱、類名稱、包名稱都應該命名的有意義，不要過度追求簡短，從而胡亂縮寫 。如果你的英文不夠好，建議必備有道詞典。堅決不要用拼音，不要裝可愛，每一個單詞都應該是有意義的。另外要重視 IDE 的單詞提示，不要漏掉或者亂序字母。
函式
函式最緊要追求的就是短小 和只做一件事。短小這一點大家都應該瞭解。往往我們為了讓函式複用，傳入 Boolean 引數使其具備兩種功能，其實這種寫法是不建議的，當然也要見機行事。
我們一直在強調少用 If-else 多用 Switch。但是 Switch 語句也會造成濫用的情況。即 Switch 語句，前面說了函式最好只做一件事，但是 Switch 語句天生就要做很多事，這不是違背了之前的理論嗎？另外 Switch 語句違背了單一職權原則和開發閉合原則。另外書中闡述 Switch 語句可能多次與同一個物件事件關聯，從這個角度來說，書中建議將 Switch 語句隱藏到抽象工廠中去。
函式的名稱不要怕長，一定要清晰，個人見過專案中的程式碼這種簡單的不得了的函式命名：share()/delete()/download()，說真的這種命名真的無力吐槽了。
函式應該無副作用 ，要非常小心你的函式會不會對一些全域性變數造成修改。輸出的引數，對全域性的影響。
函式最完美的引數應該是零引數、其次是一個。如果引數有三個以及三個以上，就要考慮封裝引數物件了。
使用異常程式碼錯誤碼。這一點很有用，錯誤碼如果過多會導致多層次的 If-else 語句。異常的話，可以將可能出錯的程式碼都包裹在 Try-Catch 裡面，統一返回異常。另外一點就是 Try-Catch 會影響程式碼的排版，美觀性收到很大影響，此時建議將 Try-Catch 中的程式碼抽離成函式。避免 Try-Catch 搞亂了程式碼排版和結構。
另外最後兩點就是函式不要重複自己和結構化程式設計。重複不必多說，一個尷尬的局面就是需要修改時，要多處修改。結構化程式設計，意思是說程式碼應該只有一個出口和入口。儘量少一些 Break、Return、Continue 等。這一點仁者見仁，持保留意見。
類
將類這一節放在函式下面講好像更合適。對於類來說，很多要注意的地方跟函式其實差不多。但是還是單獨強調下較好。
第一：類應該短小。書中有說：系統應該由許多短小的類而不是少量巨大的類組成。另外一點就是保持內聚，說實話對這一點我的體會還不怎麼深刻。在業務程式碼中，我的理解可能就是能寫區域性變數就寫區域性變數(本質上是作用域的概念)，另外一種理解就是模組(函式或者類)應該儘可能的獨立完成自己的任務，減少對其他模組的依賴。
另外一點就是設計類時候應該考慮到日後的修改，因為畢竟後面可能會一直持續維護。術語即對擴充套件開發，對修改關閉。當然，做到這一點很難。
註釋
這一節一開始就強調註釋不能美化糟糕的程式碼 。另外很多人都說好的程式碼是不要註釋的。不過我覺得註釋肯定是要的，不過應該簡短清晰。很多地方是要註釋 Why 而不是 How 和 What.另外從註釋的角度我們回溯一下命名，從這裡可見好的命名、可讀性強的命名是可以減少不必要的註釋的。另外個人覺得最基本的是一個類的開頭一點要有註釋，起碼應該有日期、作者資訊，負責一點最好寫一下類的作用，否則很坑後面的程式碼維護者。
不要廢話註釋、不要讓註釋搞亂程式碼的排版結構。不要的大規模的程式碼，也不要用註釋，可以用版本控制，寫好 Commit 資訊處理好。
格式
格式這一點，個人追求的也是論文類格式。不過書中倡導的是向報紙的排版學習。不要多餘空格，程式碼格式統一化，括號放的位置統一化。這些都是要平常注意的。不過最好團隊能夠統一。記住常用格式化快捷鍵。
錯誤處理
這個章節首先還是強調的是使用異常而不是錯誤碼，特別針對 Java 這類支援異常的語言。另外在程式碼編寫過程中，不要輕易或者堅決不要返回 Null 值，這是坑人的做法。同時，更不要傳遞 Null 值給其他人。