GNUコーディング標準

GNUコーディング標準は、 GNUシステム内で一貫して動作するプログラムを作成するための規則とガイドラインのセットです。GNUコーディング標準は、リチャード・ストールマン氏と他の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 ; /* ファイル名の最後のスラッシュの後の最初の文字へのポインタ。 */ int wilma ; /* 宇宙のおおよそのサイズ。 */ int fred ; /* `bar' フィールドの最大値。 */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 C コードの書式設定スタイルの非常に特徴的な点です。括弧の前に必ずスペースを入れることも同様に特徴的です。GNU スタイルで書式設定されたすべてのコードは、閉じ括弧、角括弧、または丸括弧が、対応する開き括弧の右側、または同じ列に表示されるという特性を持っています。

GNU EmacsはGNUシステムと密接に統合されているため、Cコードの自動フォーマットをGNUコーディング標準に合わせます。^{[ 1 ]} GNUコーディング標準から逸脱するような方法でコードのフォーマットを手動で変更するのではなく、追加の括弧を挿入するなどして、Emacsに適した形式でコードを記述することで、フォーマットされたコードのレイアウトを調整できます。

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

これらの基準は、英語によるコメントの重要性を強く強調している。

GNUプログラムのコメントは英語で記述してください。英語は、世界中のほぼすべてのプログラマーが読める唯一の言語だからです。英語での記述が苦手な場合は、できる限り英語でコメントを記述し、他の人に書き直してもらってください。どうしても英語でコメントを記述できない場合は、協力してくれる人を見つけて、コメントを英語に翻訳してもらってください。

コメントは、完全な文で、すべて大文字で始め、各文の最後に2つのスペースを入れる必要があります（Emacsが文の終わりと次の文の始まりを認識できるようにするため）。

長くて複雑なプリプロセッサ条件の場合、すべての と には#else、以下のコード ( の場合) または上記のコード ( の場合)#endifの条件を説明するコメントが必要です。#else#endif

/usr規格では、すべてのプログラムが、およびが読み取り専用でマウントされ/etcている場合でも動作できることが求められています。したがって、内部目的で変更されるファイル（ログファイル、ロックファイル、一時ファイルなど）は、またはのどちらにも保存してはなりません。ただし、内のシステム構成ファイルを更新するプログラムについては例外です。また、ユーザーが明示的に同じディレクトリ内のファイルを変更するように要求した場合、ディレクトリにファイルを保存することも例外です。/usr/etc/etc

GNUコーディング標準では、移植性の問題が次のように定義されています。Unixの世界における移植性とは「Unix間での」移植性を意味します。GNUプログラムにおいては、このような移植性は望ましいものの、不可欠ではありません。

標準規格によれば、GNUプログラムはGNU Cコンパイラという単一のコンパイラでコンパイルされ、GNUシステムという単一のシステムでのみ実行されるように設計されているため、移植性の問題は非常に限定的である。

ただし、移植性に関する問題が一つあります。それは、標準規格でプログラムが異なるCPUタイプ上で動作することが明記されている点です。標準規格では、GNUは16ビットシステムをサポートしておらず、今後もサポートする予定はないとされていますが、32ビットシステムと64ビットシステムへの対応は絶対に必要だとされています。

Gnits規格は、ソフトウェアのプログラミング、保守、配布に関する標準規格と推奨事項の集合体です。これらは、「GNU nit-pickers」（GNU nit-pickersの略）と自称するGNUプロジェクトメンテナーのグループによって公開されています。そのため、これらはアドバイスであり、フリーソフトウェア財団やGNUの方針ではありませんが、Gnits規格の一部は、フリーソフトウェアプログラマーの間で広く採用されています。

Gnits規格は、GNU標準規格の拡張、改良、および注釈です。しかし、GNUにおいて規範的なものではなく、GNUメンテナーはGnits規格に従う義務はありません。とはいえ、メンテナーやプログラマーは、GNU標準規格に従うための良いアイデアや、一部のGNU標準規格がなぜそのように決定されたのかについての暫定的な非公式な説明をGnits規格の中に見出すことがよくあります。GnitsとGNU標準規格の間には相違点はほとんどなく、相違点がある場合は常に明確に注記されています。

これらの規格は、ソフトウェアアーキテクチャ、プログラムの動作、人間とコンピュータのインタラクション、C言語プログラミング、ドキュメンテーション、およびソフトウェアリリースといった側面を扱っています。

2008年の時点で、Gnits規格には、それらが衰退しており、もはや積極的にメンテナンスされていないという注意書きがあり、読者にはGnulib、Autoconf、およびAutomakeのマニュアルを参照するように促している。これらのマニュアルは、多くの同じトピックを扱っていると言われている。

GNUコーディング標準は主にGNUプロジェクトで使用されていますが、その使用はGNUプロジェクトだけに限定されるものではありません。

Linuxカーネルはこのスタイルをカーネルコードには強く推奨しておらず、このスタイルを軽蔑的に言及しています。「まず、GNUコーディング標準のコピーを印刷して、読まないことをお勧めします。燃やしてください。素晴らしい象徴的なジェスチャーです。」^{[ 3 ]}スティーブ・マコーネルも著書『Code Complete』の中でこのスタイルの使用を推奨しておらず、このスタイルを使用しているコードサンプルには「コーディングホラー」アイコンを付けて、特に危険なコードを象徴し、中括弧のために余分なインデントレベルが必要になるため可読性を損なうと述べています。^{[ 4 ]}

• GNUウェブサイト上のGNUコーディング標準
• GNUコーディング標準に準拠したEclipseコードスタイルフォーマッタ