GNUコーディング標準

GNUコーディング標準は、 GNUシステム内で一貫して動作するプログラムを作成するための一連のルールとガイドラインです。GNU コーディング標準は、リチャード・ストールマンとその他の GNU プロジェクトのボランティアによって作成されました。標準ドキュメントはGNU プロジェクトの一部であり、GNU の Web サイトから入手できます。この標準ドキュメントはCで GNU 用のフリー ソフトウェアを作成することに重点を置いていますが、その多くはより一般的に適用できます。特に、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 (ウィルマ); 

      チェックへ移動; } 
    

  0 を返す; } 

ブロックを文として一貫して扱うこと (インデントのため) は、括弧の前の必須のスペースと同様、GNU C コード フォーマット スタイルの非常に特徴的な機能です。GNU スタイルでフォーマットされたすべてのコードでは、閉じ括弧、角括弧、または括弧がそれぞれ対応する開き区切りの右側、または同じ列に表示されるという特性があります。

GNU EmacsはGNUシステムと緊密に統合されており、GNUコーディング標準に一致するようにCコードを自動的にフォーマットします。^[1] GNUコーディング標準から外れるように手動でコードフォーマットを変更するのではなく、たとえば追加の括弧を挿入するなど、よりEmacsに適した形式で記述することで、コードのフォーマットされたレイアウトを微調整できます。

「式を複数行に分割する場合は、演算子の後ではなく、演算子の前で分割してください。」^[2]

例えば：

if ( foo_this_is_long && bar > win ( x , y , z ) &&残りの条件)        
     

基準では英語の コメントの重要性を強く強調しています。

GNU プログラム内のコメントは英語で書いてください。英語は、あらゆる国のほぼすべてのプログラマーが読める唯一の言語だからです。英語が苦手な場合は、できるだけ英語でコメントを書いて、他の人に書き直しを手伝ってもらってください。英語でコメントを書けない場合は、一緒に作業してくれる人を見つけて、あなたのコメントを英語に翻訳してください。

コメントは完全な大文字の文で構成し、各文の後に 2 つのスペースを入れます (これにより、Emacs は 1 つの文が終了し、次の文が始まる場所を判断できます)。

長いまたは複雑なプリプロセッサ条件の場合、#elseおよび ごとに、下側 ( の場合) または上側 ( の場合)#endifのコードに対する条件を説明するコメントが必要です。 #else#endif

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

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

標準によれば、GNU プログラムは 1 つのコンパイラ ( GNU C コンパイラ)でコンパイルされ、1 つのシステム (GNU システム) でのみ実行されるように設計されているため、移植性の問題は非常に限られています。

ただし、移植性の問題が 1 つあります。それは、標準ではプログラムが異なるCPUタイプで実行する必要があることが明確にされていることです。標準では、GNU は 16 ビット システムをサポートしておらず、今後もサポートしないとされていますが、さまざまな 32 ビット システムと 64 ビット システムをすべて処理することが絶対に必要です。

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

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

• Gnitsの基準

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