代碼整潔之道閱讀筆記 一

1、命名

1. 全員生產維護
   • 整理
   • 整頓
   • 清楚
   • 清潔
   • 身美
2. 簡單代碼規則
   • 能經過全部測試
   • 沒有重複代碼
   • 體現系統中的所有設計理念
   • 包括少許的實體，好比類、方法、函數等
3. 變量的命名
   • 名副其實，它爲何會存在，它作什麼事，應該怎麼用。若是須要註釋來解釋，那就不是名副其實

int d//消逝的時間 以天計 int elapsedTimeInDays int daysSinceCreation int daysSinceModification int fileAgeInDays

- 有意義的命名，  不要$a $d 等 - 命名不要冗餘, 好比在table的命名裏永遠不加table 變量的命名裏不加variable - 能讀得出來的命名 不要 genymd(生成年月日) 換成generationTimeStamp

4. 類的命名
   • 類名和對象名應該以名詞或者名詞短語爲主，避免使用動詞
   • 方法名 儘可能使用動詞或者動賓結構並依Javebean標準加上get set is 前綴 5.終上所述，明確！就是要明確！不要前綴不要一語雙關等等。 6.最後的話：取好名字最難的地方在於須要良好的描述和共有文化背景。與其說這是一種技術、商業或者管理問題，還不如說是一種教學問題。其結果是，這個領域內的許多人都沒能學會作得很好。

2、函數

1. 函數就應該短小 一個函數最好不要超過20行
2. 函數應該只作一件事，作好這件事，只作這件事
3. 函數要麼作什麼，要麼回答什麼，不要二者兼有

if(set('name','password')); //改成 if(attributeExists('name')){ setAttribute('name','password'); }

4. 別重複本身: 聽從DRY規則
5. 如何寫出這樣的代碼：寫代碼和寫別的東西很像。在寫論文或文章時，你先想什麼就寫什麼，而後再打磨它。初稿也許粗陋無需，你就斟酌推敲，直至達到你心目中的樣子
6. 小結：每一個系統都是使用某種領域特定語言搭建，而這種語言是程序員設計來描述那個系統的。函數是語言的動詞，類是名詞。編程藝術是且一直是語言設計的藝術。

3、註釋

1. 只有當程序表達失敗時，才須要用得上註釋，真正好的代碼是不須要註釋的
2. 註釋不能美化糟糕的代碼
3. 用代碼來闡述永遠好過垃圾代碼+註釋

#example if((employee.flags & HOURLY_FLAG)&&(employee.age)>65) 仍是這個？ if(employee.isEligibleForFullBenefits())

4. 好的註釋：有些註釋是必須的，也是有利的
   1. 法律信息
   2. 提供信息的註釋
   3. 對意圖的解釋
   4. 闡釋 註釋把某些晦澀難明的參數或者返回值的意義翻譯爲某種可讀形式
   5. 警示
   6. TODO 註釋 這個就很是有必要了，未來須要怎麼作，我的挺喜歡用的，當前時間段內，因爲某些緣由尚未作，可是之後會須要作的事
   7. 放大 和警示差很少
5. 壞註釋，大多數註釋都屬此類。一般，壞註釋都是糟糕的代碼的支撐或藉口，或者對錯誤決策的修正，基本上等於程序員自說自話。
   1. 多餘的註釋
   2. 誤導性的註釋
   3. 循規式註釋，好比每一個字段都加註釋， title author等簡單明瞭的變量
   4. 日誌式註釋，由於有代碼控制 SVN GIT 不須要把每次變化都經過註釋表示
   5. 廢話註釋
   6. 能用函數或者變量時，就別用註釋
   7. 歸屬和署名 年代越久越和原做者不要緊
   8. 註釋掉的代碼，直接幹掉代碼整潔之道閱讀筆記