前情提要
每個專案開發，都是由多個工程師來完成，就算只有一個人，隨著專案增量，你便會與過去的你面對面，這時候程式碼的可讀性高低就會成為左右你開發效率的一塊石頭，這篇就來說說幾個程式碼管理的小撇步。
Region
程式碼區塊，是最簡單可以把程式碼分類的方法，得益於各種 IDE 、編輯器都非常方便了，無論使用哪一種基本上都能將 region 區塊摺疊起來閱讀。我是比較喜歡使用 VS Code
VS Code
Visual Studio
Visual Studio
Early Return
這是很基本的程式碼撰寫風格，能有效解決一些波動拳 if-else 的問題。
有些更單純的賦值操作，應該用三元運算子、模式匹配來完成
不妨將條件反轉改成
Partial Class
很多人不知道可以使用 Partial 這個關鍵字將一個 class 分別寫在不同的腳本內，以此來達到程式碼的分類。
Summary
在多人協作中最常接其他人的方法來用，儘管方法名稱命名得很好了，有時候還是不太知道傳入的參數、回傳的值在做些甚麼事情。
同樣得益於編輯器進步，這時候有寫 summary 告訴其他人這個方法的用法就很重要。
在 Visual Studio 內預設就有/// 三撇生成 summary 的功能，而 VS Code 需要安裝插件。
有使用到泛型時，類型約束、回傳的類型最好要明確說明
C# 的 Summary 是使用 XML 來撰寫
VS Code
Visual Studio
Git Commit / Message
首先， commit 盡量不要包山包海，盡可能一個 commit 只做一個 feature 、修一個 bug 。
雖然協作時審 PR 很花時間（所以常常口頭上說一下就給勾勾了），但比起看 PR 內容，我更常用 commit 來知道這次的 PR 做了些啥。
硬性的撰寫格式要由團隊成員達成共識，比較有趣且好用的案例像是 GitMoji 。
Summary 的部分，我自己習慣的寫法是：
< Add / Fix / Remove > < Subject >
而 Body 的部分逃不開 Implement 、Refactor 等關鍵字。一個好的 commit message 通常包含了：
- 做了啥
- 為了啥
- 如何做到
但也要注意不要過長，如果為了一個 commit 花太長時間編輯 message 可就本末倒置了。
後記
對於這個專案程式碼管理的系列我想出個 2~3 篇，算是有感而發吧，近幾個專案都是接做一半的，而我也正在重構半年前開發到一半的遊戲，因為沒有做好程式碼的整理，導致讀程式碼壓縮了實作的時間。
離上次開方格子寫文章隔了半個月，這裡終於支援程式碼了！可能有越來越多跟程式設計相關的創作者加入了，目前支援的語言不多，我也還是用 gist 來寫示範以方便修正，但滿意外有支援 Rust 的。
另外有一篇關於 Unity Screen Space 的文章一直卡在那邊難產，應該會找時間把它完成......
