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 更友好的形式。

分割长行

编辑

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

例如:

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 编码标准打印一份,但不去读它,而是把它烧掉,这是个非常好的象征性动作。”[2]

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

参见

编辑

参考文献

编辑
  1. ^ GNU Coding Standards. www.gnu.org. [2020-11-29]. (原始内容存档于2021-12-07) (英语). 
  2. ^ Linux kernel coding style — The Linux Kernel documentation. www.kernel.org. [2017-10-12]. (原始内容存档于2017-07-04) (英语). 
  3. ^ McConnell, Steve. Code Complete: A practical handbook of software construction. Redmond, WA: Microsoft Press. 2004: 746–747. ISBN 0-7356-1967-0. 

外部链接

编辑