這次要深入探討一些程式碼撰寫的習慣,不一定會減少程式碼量,但基本上能提高專案效率。
多使用區域變數,減少使用成員變數、屬性,在方法行為單一職責化的情況下可以大幅降低程式碼的閱讀難度。
另外使用區域變數能夠讓方法的結果更容易預測,能更好寫出測試。
關注點分離是很多語言框架實作的基礎,有實作過後端的同學應該不陌生。雖然 Unity 沒有特定說明程式碼撰寫風格,但將顯示與邏輯分離在多人協作時能提供很好的整合能力。
Unity ECS 其實變相地強迫使用者做到關注點分離
綜合以上優缺點,如果是小專案或是要快速產出 Mock 版的情況下不推薦使用。
微軟有為 CSharp 規範一套習慣。
在 Unity 裡面最常遇到需要指定物件參考,基於對物件的封裝欄位(Field)不應該公開,而能夠公開的會是屬性(Property)、方法(Method),但 Property 很難在 Editor 底下進行序列化,所以當一個類別的成員變多時,沒有系統的命名會疑惑程序猿。
另外值得一提的是換行習慣,由於 C# 不倚靠縮排來達成程式碼區塊,適時地換行是值得鼓勵的,我們來看下面這段 LINQ 程式碼:
userList.Where(user => user.isVip).Range(0, 20).SelectMany(user => user.Characters).ToList().Foreach(c => AddDLC(c));
應該很難直接看出這行到底做了啥,所以可以改成
userList
.Where(user => user.isVip)
.Range(0, 20)
.SelectMany(user => user.Characters)
.ToList()
.Foreach(c => AddDLC(c.id));
就能清楚條列出這行程式碼要做的是給前 20 位 VIP 玩家的所有角色新增 DLC。雖然這是滿極端的案例就是了......
最後提一下程式碼縮排跟括弧換行,基本上現在的 IDE 都提供相當優秀的程式碼格式化功能,但需要注意的是如果是接手其他人的程式碼,亂按格式化可能會導致版控衝突。
這次說的內容比較偏概念,通過增加些許的程式碼量,進而提高效率,在多人協作時更能減輕交接時的困難。