如何寫出不太壞的程式碼
摘要：
2019-02-28
如何寫出不太壞的程式碼
本來想把標題定為“如何寫出好程式碼”的，但是轉念一想，覺得自己沒那麼牛逼，就改成了不太壞的程式碼。只要不要寫出太糟糕的程式碼，不就是好程式碼了嗎？
以下只是個人的一些總結，如有異議，請出門右轉。
1.注重命名
包括檔名，變數名，...
2019-02-28
如何寫出不太壞的程式碼
本來想把標題定為“如何寫出好程式碼”的，但是轉念一想，覺得自己沒那麼牛逼，就改成了不太壞的程式碼。只要不要寫出太糟糕的程式碼，不就是好程式碼了嗎？
以下只是個人的一些總結，如有異議，請出門右轉。
1.注重命名
包括檔名，變數名，方法名。一般變數名以功能來命名，看它的名字就能知道它的用途是什麼 遵循一些命名規範。Java中成員變數名一般以m開頭，而OC中的成員變數一般以_開頭
2.遵循低耦合，高內聚的原則編寫程式碼
具體表現遵循分層分模組原則，底層模組不能依賴上層模組，邏輯層不依賴介面，絕不要把邏輯層程式碼和介面程式碼混在一起
3.針對介面程式設計，而不是實現程式設計
當一個類要暴露一些方法給外部呼叫或者通訊時，先定義好介面。介面定義應該簡單明瞭，不容易引起歧義，介面儘量少。最後才考慮內部實現，而且儘量不暴露給外部，儘量不需要外部知道內部是如何實現的
4.一個類的程式碼量儘量不要太大，一個方法只做一件事情
一個類（或者一個方法）的程式碼越多，出錯的概率越大。一個類三到5百行程式碼最佳。如果一個類的程式碼太多，就要考慮這個類是不是做的東西太多了，可以拆分一下。當然，有些類（例如一些SDK基類）無法避免太大，就要好好遵循第5條準則。而一個方法也不要做太多東西，只做一件事情就可以。
5.類的方法和變數的排布應該遵循一定規則
例如：
- 相同功能的方法儘量放在一起。
- 生命週期方法應該儘量放一起，按時序排列
- 公開方法排在前面，私有方法排在後面
- OC可以充分使用category特性，同一類的方法放一起（swift的Extension也一樣）
6.儘量不重複寫程式碼，特別是邏輯程式碼
- 重複程式碼難維護，出現bug要每個重複地方都去修改，容易漏掉。
- 加入一個專案，在實現某個功能之前，可以先看看專案裡有沒有已經實現過這個功能的程式碼。沒有必要重複造輪子。如果有，但是寫得不好，或者有bug，可以跟原作者溝通讓其改進，或者自己改進。除非不得已，不要重複實現。如果人人一不爽就自己弄一套，那久而久之都是重複程式碼，難以維護。如果相互改進，則大家一起進步。
- 不過呢，如果一部分的程式碼重複可以為架構帶來好處，方便維護，那是可以的，值得的。例如程式碼的重複可以減少兩個模組之前的通訊和關聯，那是可以的。
7.經常區域性重構
沒有人能一下子就寫出很好的程式碼，經常重構可以減少程式bug，也可以提升自己的程式碼質量
書籍推薦
這裡推薦一本書籍，專門講重構的，有專門講如何對變數命名的，是一本好書。《重構，改善既有程式碼的質量》
Category:技術 Tagged:iOS開發 Android開發