User:LS Hower/GNU编码标准

GNU 编码标准是 GNU 项目编写程序代码的一套规则指南，由 Richard Stallman 和其他 GNU 项目志愿者撰写。它的文档也是 GNU 项目的一部分，可以从 GNU 网站获取。它本身是指导 GNU 自由软件的 C 语言代码的，但许多规定都可以推广使用。GNU 鼓励贡献者们（包括不使用 C 语言实现的）遵循这一标准。

代码格式

GNU 编码标准对 C 语言代码的格式有着严格的规范。下面是一个典型的例子：

int
main (int argc, char *argv[])
{
  struct gizmo foo;

  fetch_gizmo (&foo, argv[1]);

 check:
  if (foo.type == MOOMIN)
    puts ("It's a moomin.");
  else if (foo.bar < GIZMO_SNUFKIN_THRESHOLD / 2
           || (strcmp (foo.class_name, "snufkin") == 0)
               && foo.bar < GIZMO_SNUFKIN_THRESHOLD)
    puts ("It's a snufkin.");
  else
    {
      char *barney;  /* Pointer to the first character after
                        the last slash in the file name.  */
      int wilma;     /* Approximate size of the universe.  */
      int fred;      /* Max value of the `bar' field.  */

      do
        {
          frobnicate (&foo, GIZMO_SNUFKIN_THRESHOLD,
                      &barney, &wilma, &fred);
          twiddle (&foo, barney, wilma + fred);
        }
      while (foo.bar >= GIZMO_SNUFKIN_THRESHOLD);

      store_size (wilma);

      goto check;
    }

  return 0;
}

可以看到，标准总是将块视为语句来缩进。每一对花括号、方括号或括弧都要么在同一行，要么在同一列。

一般可以考虑以 GNU Emacs 为可靠权威，格式化得到 GNU 编码标准的代码。在 Emacs 里缩进起来很难看的代码，经过修改（比如添加括号），可以变成对 Emacs 更友好的形式。

分割长行

“将表达式拆分成多行时，要在一个运算符的前面拆分，不要在它后面拆分。”

例如：

if (foo_this_is_long && bar > win (x, y, z)
    && remaining_condition)

注释

标准里特别强调了英文注释的重要性。

在 GNU 程序中写注释，请使用英文，因为几乎各国所有的程序员都能够读懂英文。如果英文写得不太好，也请尽量用英文写，然后请其他人帮忙修改。如果无法用英文写评论，那么请找人和你一同工作，将你的注释译成英文。

注释是由完整的句子组成的，句子的首个字母是大写的。每个句子后面跟两个空格。Emacs 也可以以此判断一个句子在哪里结束，下一个句子从哪里开始。

进行条件判断的预处理指令，比较长或者比较复杂的，每一个#else和#endif都应附一条注释，解释测试条件。

文件

标准要求，在/usr和/etc以只读方式挂载时，所有程序也都能够运行。因此，出于内部目的修改的文件（日志文件、锁定文件、临时文件等）不应存储在这两处。一个例外是要更新/etc 中的系统配置文件，另一个是用户明确要求需要修改。

可移植性

GNU 编码标准对可移植性有着这样的定义：在 Unix 世界里的可移植性，是说“在 Unix 之间”；在程序中，这种可移植性值得拥有，但不是一定要有。

根据这一标准，可移植性问题不大。因为源代码的编写只考虑 GCC（GNU C 编译器）的编译行为，程序也只在一个系统——GNU 系统上运行。

但是仍然有一个可移植性问题。标准明确规定，程序应能够在各类 CPU 上运行。标准规定，GNU 不支持也不会支持 16 位系统，但必须能够应对所有不同的 32 位和 64 位系统。

批评

Linux 内核强烈反对这种风格：“建议你把 GNU 编码标准打印一份，但不去读它，而是把它烧掉，这是个非常好的象征性动作。”

Steve McConnell 在 Code Complete 一书中也建议不要使用这种风格。他认为，这样的大括号缩进让代码可读性降低了。他将这样的示例代码标记为“编码恐怖”，表明这种代码特别危险。

参见

• Gnits标准

外部链接

• GNU 网站上的 GNU 编码标准
• GNU 编码标准的 Eclipse 代码样式格式化程序