- 概括總結：
- 整潔代碼：
培養整潔代碼的意識，經常維護項目中的模塊保持整潔。整潔的代碼增強可維護性，並且能提高工作效率。
2.有意義的命名：
名副其實的命名，變量名，函數，類名等。命名也有意義且能讓人讀懂。錯誤示例：名字沒有含義，a1 a2。
3.函數：
函數要單一，並且只做一件事。這樣不容易出錯，並且好複用，可維護性強大。
4.註釋：
儘量不寫註釋，註釋不要有廢話，註釋最後的作用是提供有用的信息。
5.格式：
保持項目中的風格格式統一，便於團隊開發，並且閱讀代碼方便，也有美感。
6.對象和數據結構：
對象和數據結構是兩個概念，寫代碼的時候，儘量拆分開，不要混在一起。
7.錯誤處理：
錯誤處理要調用方便，不要和邏輯業務耦合在一起。
- 開發中的實踐運用：
（1）整潔代碼：
- 整潔代碼是美觀的，並且可讀性強
- 整潔的代碼，意義清晰，直觀，可維護性強
- 沒有重複的代碼，儘量短小的實體
- 經常維護代碼的整潔，碰到修改的模塊，要順手修改
- 培養代碼整潔的意識
（2）有意義的命名：
- 變量名不要太相近，容易混亂。
- A1a2的區分沒有意義，並且容易亂，要起個排列的名字進行區分。
- 變量名不要是廢話，比如叫變量，叫class，叫list，要有意義。
- 起名要方便讀和認，不要起很奇怪的名字。
- 起名字要有特殊性，不要太大衆，不便於搜索。
- 遵循駝峯命名法
- 全局變量和局部變量，又要命名區分。比如全局帶m。
- 有些特定的名字，就不要來命名變量了，比如i，j等。
- 類名要短小，不要太長，函數名要是動詞or動詞 短語。
（3）函數：
- 函數要短小精悍，越短越好。
- 封裝的邏輯只處理單一，不要混雜在一起。
- Switch使用要避免重複。
- 函數要有個好名字，參見命名（1）。
- 參數要少，很多參數可以封裝成對象傳遞。
- 儘量避免，一元函數，一般處理event，需要有返回值。
- 參數儘量不要爲boolean，把兩個處理封裝成兩個函數。
- 函數爲動詞命名。
- 抽離trycatch代碼塊，函數返回錯誤碼。
- 相同作用的代碼，抽成共用函數。
（4）註釋：
- 少些註釋，良好的命名，就不太需要寫註釋。
- 做好判斷邏輯的函數封裝，可以少寫註釋。
- 註釋是來提供信息（約定俗成的信息等）。
- 闡述邏輯。
- TODO註釋，添加工作列表。
- 不要寫多餘無用的註釋。
（5）格式：
- 代碼從上到下排列，變量，函數等。
- 相同屬性的代碼之間，可以關係更緊密，沒有空行，比如變量。
- 項目格式化文件，敲代碼的時候，多用，保持風格一致，縮進，排列。
（6）對象和數據結構：
- getset封裝的是本地，具體實現是私有不可見的。
- 面向對象和麪向過程，看情況選擇，並不是某種就特別好。
- 迪米特Demeter法則，模塊操作對象，不需要了解對象內的數據實現。
- 避免火車失事寫法，即：一連串的函數調用。
- 避免混雜，對象和數據結構要分開。
（7）錯誤處理（強固又整潔的代碼）：
- 根據返回碼對應處理相應的情況，不要和邏輯摻雜在一起。
- 可能會拋出異常的代碼，需要使用try-Catch-finally捕捉。
- 使用不可控異常處理，可控異常處理維護成本高。
- 在異常可能發生的代碼，添加日誌記錄操作行爲，便於修改問題。
- 記錄異常時，可以直接記錄錯誤類型，不用根據不同的錯誤類型打印日誌，減少無用代碼。
- 異常處理需要添加開關，可以選擇處理異常，也可以不處理。
- 異常處理，不要返回null。增加了判空和後續調用的工作量。
- 參數不要傳null，容易空異常崩潰，還要添加判空處理。
