《代碼整潔之道》
一、有意義的命名
1.1 名副其實
它該告訴你，它爲什麼會存在，它做什麼事，它應該怎麼用。如果名稱需要註釋來補充，就不算名副其實
如int d; //消逝的時間，以日計
1.2 避免誤導
- 避免留下掩藏代碼本意的錯誤線索
- 應當避免使用與本意相悖的詞
如accountList，但是它本身可能不是List類型
1.3 作有意義的區分
不要以數字系列區分，如a1,a2廢話是另一種沒意義的區分，如Product與ProductInfo或ProductData- 要區分名稱，就要以讀者能鑑別不同之處的方式來區分
1.4 使用讀得出來的名稱
如genymdhis,讀起來就很麻煩
1.5 使用可搜索的名稱
單字母和數字常量很難在文字裏找出來，而MAX_CLASSES_PRE_STUDENT就很容易
1.6 避免使用編碼
即不要把類型或作用域編進名稱裏
1.7 避免思維映射
不應當讓讀者在腦中把你的名稱翻譯爲他們熟知的名稱
如r作爲url的別名，ad作爲address的縮寫
1.8 類名
- 類名和對象名應該是名詞或名詞短語
類名不應當是動詞
1.9 方法名
方法名應當是動詞或動詞短語，如deletePage
1.10 別扮可愛
意思就是別太幽默，別人可能不懂你的幽默
1.11 每個概念對應一個詞
給每個抽象概念選一個詞，並一以貫之
如同一堆代碼又有controller，又有manager，又有driver，就會令人困惑
1.12 別用雙關語
避免同一個單詞用於不同的目的
1.13 使用解決方案領域的名稱
記住，只有程序員纔會讀你的代碼
1.14 使用源自所涉問題領域的名稱
如果不能用程序員熟悉的術語來給手頭的工作命名，就採用從所涉問題領域而來的名稱吧
1.15 添加有意義的語境
你需要有良好命名的類、函數或名稱空間來放置名稱，給讀者提供語境
如添加前綴addrFirstName、addrLastName、addState
1.16 不要添加沒用的語境
如不要在每個類名前加入項目名
1.17 總結
取好名字最難的地方在於需要良好的描述技巧和共有文化背景
與其說這是一種技術、商業或管理問題，還不如說是一種教學問題
二、函數
2.1 短小
函數的第一規則是要短小
函數不該有100行那麼長，20行封頂最佳。
注：作者這本書介紹的語言是Java，其他編程語言有差異，求同存異吧，主要是體會作者的意思
2.2 只做一件事
函數應該做一件事。做好一件事。只做一件事，並且要儘量的短小。
問題在於很難知道那件該做的事是什麼
要判斷函數是否不止做了一件事，就是看是否能再拆出一個函數來
2.3 每個函數一個抽象層級
直頂向下讀代碼：向下規則
我們想要這樣讀程序：程序就像是一系列TO起頭的段落，每一段都描述當前抽象層級，並引用位於下一抽象層級的後續TO起頭的段落
2.4 switch語句
確保每個switch都埋藏在較低的抽象層級，而且永遠不重複
2.5 使用描述性的名稱
沃德原則：如果每個例程都讓你感到深合己意，那就是整潔的代碼
2.6 函數參數
用盡量少的參數，參數不易對付，它們帶有太多概念性
最理想的參數是0,其次是1,再次是2.儘量避免3個。有足夠特殊的理由才能用3個以上函數
2.7 無副作用
函數承諾只做一件事，就不要做其他被藏起來的事
2.8 分割指令與詢問
函數要麼做什麼事，要麼回答什麼事，但二者不可兼得。
2.9 使用異常代替錯誤返回碼
2.10 別重複自己
避免在函數中重複使用代碼
2.11 結構化編程
2.12 如何寫出這樣的函數
寫函數的一開始都是冗長複雜的，之後要用心分解函數、修改名稱和消除重複
三、註釋
別給糟糕的代碼加註釋 - 重新寫吧。
唯一真正好的註釋是你想辦法不去寫註釋
3.1 註釋不能美化糟糕的代碼
與其花時間解釋你搞出的糟糕的代碼的註釋，不如花時間清潔那堆糟糕的代碼
3.2 用代碼來闡述
3.3 好註釋
- 法律信息 //有時，公司代碼規範要求編寫與法律有關的註釋。例如版權和著作申明。
- 提供信息的註釋 //這類註釋有時管用，但更好的方式是儘量利用函數名稱傳達信息
- 對意圖的註釋
- 闡釋
- 警示 //用於警告其他程序員會出現某種後果的註釋
- TODO註釋 //有理由用//TODO形式在源代碼中放置要做的工作列表
- 放大 //有的代碼可能看着有點多餘，但編碼者當時是有他自己的考慮，這個時候需要註釋下這個代碼的重要性。避免後面被優化掉。
3.4 壞註釋
- 喃喃自語
- 多餘的註釋
- 誤導性註釋
- 循規式註釋 //就是說不用每個函數都要有Javadoc，每個變量都要有註釋
- 日誌式註釋
- 廢話註釋
- 可怕的註釋
- 能用函數或變量時就別用註釋
- 位置標記
- 括號後面的註釋
- 歸屬與署名
- 註釋掉的代碼
- HTML註釋
- 非本地信息 //請確保註釋描述了離他最近的代碼
- 信息過多
- 不明顯的聯繫 //註釋及其描述的代碼之間的聯繫應該顯而易見
- 函數頭
四、格式
4.1 格式的目的
代碼的格式關乎溝通，而溝通是專業開發者的頭等大事
代碼的可讀性會對以後可能發生的修改行爲產生深遠的影響
4.2 垂直格式
4.2.1 向報紙學習
名稱應當簡單且一目瞭然。名稱本身應該足夠告訴我們是否在正確的模塊中。源文件最頂部應該給出高層次概念和算法。細節應該往下漸次展開，直到找到源文件中最底層的函數和細節。
4.2.2 概念間垂直方向上的區隔
幾乎所有的代碼都是從上往下讀，從左往右讀。每行展現一個表達式或一個子句，每組代碼行展示一天完整的思路。這些思路用空白行區隔。
4.2.3 垂直方向上的靠近
如果說空白行隔開了概念，靠近的代碼行則暗示了它們之間的緊密關係
4.2.4 垂直距離
關係密切的概念應該互相靠近，應避免迫使讀者在源文件和類中跳來跳去
變量聲明應儘可能靠近其使用位置
實體變量應該在類的頂部聲明
相關函數。某個函數調用另一個，應該把它們放在一起，並且調用者在前，被調用者在後
概念相關的代碼應該放在一起。相關性越強，彼此之間的距離就該越短
4.2.5 垂直順序
一般來說，我們想自上而下展示函數調用依賴順序。即調用在前，被調用在後。
4.3 橫向格式
4.3.1 水平方向上的區隔與靠近
4.3.2 水平對齊
4.3.3 縮進
依靠縮進，來判斷當前代碼在什麼範圍中工作
4.4 團隊規則
同組開發人員應認同同一種代碼風格，並且每個人都應遵循這種風格
敬請期待後續章節 …