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. 

外部連結

編輯