-
專案內的代碼為專案成員所共有
自己的 code 會被別人使用、修改；同樣自己也有機會去修改別人的 code。因此撰寫代碼時最重要的是清楚明瞭，避免特殊術語或縮寫，以方便他人或將來的自己閱讀。
-
保持本地工作用副本 (working copy) 為最新版
隨時
svn update，每日至少必須上午下午各更新一次。以避免本地端代碼與 repository 上的內容落差過大，造成版本衝突，增加不必要的修改時間。 -
頻繁地簽入 (commit) 工作進度
同樣是為了減少代碼衝突。即使目前負責的功能範圍大，可能需要一兩個星期才能完成，也不要等到一兩星期做完後才 commit，必須將功能拆解，完成一小部分後便更新、簽入。最好的習慣是每天上班先 update，下班前 commit 當日進度。
-
簽入時寫上清楚註解
註解必須描述這次 commit 加了什麼功能或做了哪些修改。修 bug 的話，要能說明修正的問題，能附上 bug tracker issue number 更好。有清楚的註解，也方便之後從 svn history log 中搜尋更新歷程或代碼。
// BAD "調整" "test" "更新" // GOOD "調整闖關紀錄規則" "劇情對話測試" "修正試煉活動-BOSS波怪物少填一隻的錯誤"
-
保持代碼清潔
不要用註解的方式將一段代碼關閉：如果是某種可切換的開關，就寫成可以從設定檔或環境變數去切換；如果是舊的代碼留存備查，那就直接刪掉，SVN 歷史記錄中都可以查詢，不用捨不得刪。註解應該只作為「註釋、補充、說明」等用途，而不是拿來作為關閉代碼之用。
-
重視每一個 Compile Warning
專案中的 Compile Warning 一律都要修掉。過多的 Warning 放置不管，久而久之會讓人直接無視 Warning，從而忽視真正的問題。如果只是 Unity Editor 下的 Warning（只有編輯環境才有，Runtime 沒有），可以先用
pragma disable warning將其關閉；但 runtime 代碼下的 Warning 要真正去修掉，而不能只是將其關閉。 -
程式碼中盡量使用英文
程式碼中不管是變數名或是註解，都避免使用中文。除非寫註解時有下列情況之一：遇到遊戲中特殊名詞定義、直接自企劃文件複製貼上的片段、或是無法以英文簡單說明之內容。
程式碼的風格，以符合該程式語言社群所使用的慣例為主。舉例來說，C# 或 Java 的變數多以 camelCase 命名；而 C 或 Lua 則以小寫加底下的慣例命名。一個簡單的方法是參考該語言中的系統函式庫。
針對目前專案所使用到的幾個語言，下面列出幾份文件作為「代碼規範」的依據。專案有新人加入時，請務必先看過相關文件，再投入程式撰寫工作。
Php 的代碼規範請參考 PHP PSR 文件，特別是 PSR-2 與 PSR-3 的規範。
C# 的代碼規範以微軟的文件為主。
專案內的 Python 代碼請參考 PEP8。