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以获取确切的内容。