如何寫出不太壞的程式碼
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開發