Git/回饋/程式碼規範
< Git
此頁面的第一稿改編自 Johannes Schindelin 在 git 新聞組上公開發布的提交。[1]
- 最重要的是，我們絕不說是“它是 POSIX 標準的；我們很樂意破壞不符合標準的系統”。我們生活在現實世界中。
- 然而，我們經常說“讓我們遠離那個結構，它甚至不在 POSIX 標準中”。
- 如果你正在計劃一個新的命令，考慮先用 shell 或 perl 編寫它，這樣語義上的改變就可以很容易地更改和討論。許多 git 命令都是這樣開始的，其中一些仍然是指令碼。
專門針對 shell 指令碼（非詳盡列表）
- 我們更喜歡使用
$( ... )進行命令替換；與 `` 不同，它可以正確巢狀。從一開始，它就應該是 Bourne 指令碼的寫法，但不幸的是，它不是。 - 我們使用
${parameter-word}及其 [-=?+] 兄弟，以及它們的帶冒號的“未設定或為空”形式。 - 我們使用
${parameter#word}及其 [#%] 兄弟，以及它們的雙重“最長匹配”形式。 - 我們使用算術擴充套件
$(( ... ))。 - 不使用“子字串擴充套件”
${parameter:offset:length}。 - 不使用 shell 陣列。
- 不使用 strlen
${#parameter}。 - 不使用正則表示式
${parameter/pattern/string}。 - 我們不使用程序替換
<(list)或>(list)。 - 我們更喜歡使用“test”而不是“[ ... ]”。
- 我們不在 shell 函式前面寫噪音詞
function。
對於 C 程式
- 使用製表符進行縮排，並將製表符解釋為佔用最多 8 個空格
- 嘗試將每行限制在 80 個字元內
- 宣告指標時，星號與變數名放在一起，即“char *string”，而不是“char* string”或“char * string”。這樣更容易理解“char *string, c;”。
- 不要不必要地使用花括號。例如，
if (bla) { x = 1; }是不受歡迎的。一個灰色區域是當語句擴充套件到幾行時，或者你在它上面有一個很長的註釋。 - 嘗試使你的程式碼易於理解。你可以添加註釋，但註釋往往會在它們所描述的程式碼發生變化時過時。通常將一個函式分成兩個函式可以使程式碼的意圖更加清晰。
- 雙重否定通常比完全沒有否定更難理解。
- 一些巧妙的技巧，比如在算術結構中使用 !! 運算子，可能會讓其他人非常困惑。避免使用它們，除非有充分的理由使用它們。
- 使用 API。真的。我們有一個 strbuf（可變長度字串），幾個使用 ALLOC_GROW() 宏的陣列，一個用於排序字串列表的 path_list，一個名為“struct decorate”的雜湊對映（對映結構物件），以及其他一些東西。
#include系統標頭檔案在git-compat-util.h中。在某些系統上，某些標頭檔案在更改順序時會顯示細微的故障，因此最好將它們放在一個地方。
- ^ 請參閱提交622b80b以獲取確切的內容。