Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

專案開發規範

開發習慣

  1. 專案內的代碼為專案成員所共有

    自己的 code 會被別人使用、修改;同樣自己也有機會去修改別人的 code。因此撰寫代碼時最重要的是清楚明瞭,避免特殊術語或縮寫,以方便他人或將來的自己閱讀。

  2. 保持本地工作用副本 (working copy) 為最新版

    隨時 svn update,每日至少必須上午下午各更新一次。以避免本地端代碼與 repository 上的內容落差過大,造成版本衝突,增加不必要的修改時間。

  3. 頻繁地簽入 (commit) 工作進度

    同樣是為了減少代碼衝突。即使目前負責的功能範圍大,可能需要一兩個星期才能完成,也不要等到一兩星期做完後才 commit,必須將功能拆解,完成一小部分後便更新、簽入。最好的習慣是每天上班先 update,下班前 commit 當日進度。

  4. 簽入時寫上清楚註解

    註解必須描述這次 commit 加了什麼功能或做了哪些修改。修 bug 的話,要能說明修正的問題,能附上 bug tracker issue number 更好。有清楚的註解,也方便之後從 svn history log 中搜尋更新歷程或代碼。

    // BAD
    "調整"
    "test"
    "更新"
    // GOOD
    "調整闖關紀錄規則"
    "劇情對話測試"
    "修正試煉活動-BOSS波怪物少填一隻的錯誤"
  5. 保持代碼清潔

    不要用註解的方式將一段代碼關閉:如果是某種可切換的開關,就寫成可以從設定檔或環境變數去切換;如果是舊的代碼留存備查,那就直接刪掉,SVN 歷史記錄中都可以查詢,不用捨不得刪。註解應該只作為「註釋、補充、說明」等用途,而不是拿來作為關閉代碼之用。

  6. 重視每一個 Compile Warning

    專案中的 Compile Warning 一律都要修掉。過多的 Warning 放置不管,久而久之會讓人直接無視 Warning,從而忽視真正的問題。如果只是 Unity Editor 下的 Warning(只有編輯環境才有,Runtime 沒有),可以先用 pragma disable warning 將其關閉;但 runtime 代碼下的 Warning 要真正去修掉,而不能只是將其關閉。

  7. 程式碼中盡量使用英文

    程式碼中不管是變數名或是註解,都避免使用中文。除非寫註解時有下列情況之一:遇到遊戲中特殊名詞定義、直接自企劃文件複製貼上的片段、或是無法以英文簡單說明之內容。

代碼規範

程式碼的風格,以符合該程式語言社群所使用的慣例為主。舉例來說,C# 或 Java 的變數多以 camelCase 命名;而 C 或 Lua 則以小寫加底下的慣例命名。一個簡單的方法是參考該語言中的系統函式庫。

針對目前專案所使用到的幾個語言,下面列出幾份文件作為「代碼規範」的依據。專案有新人加入時,請務必先看過相關文件,再投入程式撰寫工作。

PHP

Php 的代碼規範請參考 PHP PSR 文件,特別是 PSR-2 與 PSR-3 的規範。

C# (Unity)

C# 的代碼規範以微軟的文件為主。

Python

專案內的 Python 代碼請參考 PEP8。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment