使用者: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 代碼樣式格式化程序