インデントスタイル

コンピュータ プログラミングにおいて、インデント スタイルは、ソース コードブロックのインデントを管理する規則(スタイルとも呼ばれます)です。インデント スタイルでは、通常、ブロックの各行の前の空白の幅 (インデント サイズ) が一定であるため、コード行が関連しているように見え、インデントの空白にスペース文字を使用するかタブ文字を使用するかが決まります。

この記事では、主に自由形式の プログラミング言語のスタイルについて説明します。名前が示すように、このような言語コードはインデント スタイルに従う必要はありません。インデントは、プログラマがコードの構造を理解するための認知負荷を軽減することを目的とした補助的な表記法です。インデントにより、制御フローに基づいて実行されるコード間の分離を明確にすることができます。

Pythonやoccamなどの構造化言語では、中括弧やキーワードの代わりにインデントを使用して構造を決定します。これはオフサイドルールと呼ばれます。このような言語では、インデントは言語プロセッサ (コンパイラやインタープリタなど) にとって意味を持ちます。プログラマはインデントのサイズを自由に選択できますが、言語のインデントルールに従わなければなりません。

この記事では、中括弧言語(中括弧、別名中括弧、別名中括弧でブロックを区切る)、特に C ファミリ言語BEGINに焦点を当てていますが、ある言語で使用される規則は別の言語に適応させることができます。たとえば、中括弧の代わりにキーワードとを使用する言語は、同じものを開き括弧として END扱うなどして適応させることができます。BEGIN

インデント スタイルはテキストベースの言語にのみ適用されます。ビジュアル プログラミング言語にはインデントはありません。

インデントスタイルは広く使用されているにもかかわらず、その価値についての研究はほとんど行われていません。1974年にWeissmanによって行われた最初の実験では、効果は見られませんでした。^[1] 2023年にMorzeckらによる実験^[2]では、ネストされたステートメントに有意なプラスの効果が見られif、インデントされていないコードはインデントされたコードよりも平均で179%多くの読み取り時間が必要でした。Hanenbergらによるフォローアップ実験^[3]では、大きな効果が確認され（ただし、その実験ではインデントされていないコードは読み取りに113%長い時間がかかりました）、読み取り時間の違いはスキップできるコード（インデントされたコードの場合）によって説明できることが明らかになりました。JSONオブジェクトに関する別の実験^[4]では、インデントされていないコードは読み取りに544%も長い時間がかかりました。

以下の表には、さまざまなインデント スタイルのコード例が含まれています。一貫性を保つために、サンプル コードのインデント サイズは 4 スペースですが、コーディング規則によって異なります。

C、C++、およびその他の中括弧プログラミング言語のコーディング スタイルの属性には、次のものが含まれますが、これらに限定されません。

• 他のコード要素に対する中括弧の配置
• タブまたはスペースの使用
• 単一ステートメント ブロックを中括弧で囲みます。支持者は、ステートメントを挿入してもインデントに反する制御フローが発生しないため、結果のコードがより安全になるという利点を挙げています。欠点として挙げられているのは、ブロックの閉じ括弧に 1 行必要になるため (else if構文とdo{}whileブロックを除く)、コードが長くなることです。

Kernighan & Ritchie (K&R) スタイルは、C および C++ コードで一般的に使用されており、多くの派生スタイルの基礎となっています。このスタイルは、オリジナルの Unix カーネル、KernighanとRitchie の著書『The C Programming Language』、および Kernighan とPlaugerの著書『The Elements of Programming Style』で使用されています。

C プログラミング言語ではこのスタイルを明示的に定義していませんが、一貫してそれに従っています。本書より:

人々は熱烈な信念を抱いていますが、歯列矯正器具の位置はそれほど重要ではありません。私たちはいくつかの人気のあるスタイルの中から 1 つを選びました。自分に合ったスタイルを選び、それを一貫して使用してください。

このスタイルでは、関数は開き中括弧と閉じ中括弧を独自の行に持ち、宣言と同じインデントで記述しますが、関数本体のステートメントはさらに 1 レベルインデントされます。ただし、関数内の複数ステートメント ブロックでは、開き中括弧は制御句と同じ行に記述されますが、閉じ中括弧は、 や などのキーワードが続かない限り、独自の行に記述されelseますwhile。

コード例:

int main ( int argc , char * argv []) { while ( x == y ) { do_something (); do_something_else (); if ( some_error ) fix_issue (); // 中括弧なしの単一ステートメントブロックelse continue_as_usual (); } final_thing (); }    

        
        
        
         
             
        
            
    
    

複数行ブロックの 非整列括弧は、古代エジプト人の空想的なポーズの腕に似ていることから、「エジプト括弧」（または「エジプト括弧」）というニックネームが付けられています。 ^{[5] [6] [7]}

単一ステートメント ブロックには中括弧がないため、 goto fail バグなどの見逃しやすいバグの原因となります。

ワントゥルーブレーススタイル ^[8]（略称1TBSまたはOTBS ^[9]）はK&Rスタイルに似ていますが、関数は宣言と同じ行に開きブレースがある複数文ブロックのようにフォーマットされ、単一文ブロックの場合はブレースは省略されません。 ^[10]

bool is_negative ( int x ) { if ( x < 0 ) { trueを返す; } else { falseを返す; } }   
        
         
      
         
    

C/C++ などの言語では必須ではありませんが、単一ステートメント ブロックに中括弧を使用すると、ステートメントを挿入しても、たとえば Apple の悪名高いgoto fail バグに見られるような、インデントと一致しない制御フローが発生しないことが保証されます。

挙げられる利点としては、開始中括弧に余分な行が不要なためK&Rよりもコードが短いこと、終了中括弧が概念的に属するステートメントと一列に並ぶこと、関数本体と複数行のステートメントブロックの両方で同じ中括弧スタイルを使用することでスタイルの一貫性が感じられることなどが挙げられます。^[11]

One True Brace Style の意味については、情報源によって意見が分かれています。ここに指定されているバリエーションであると言う人もいれば、^[10] K&R の「ハッカー用語」であると言う人もいます。^[12]

LinuxカーネルのソースツリーはK&Rの変形でスタイル化されています。^[13] Linus Torvaldsは貢献者にこれに従うよう勧めています。属性には以下が含まれます。

• インデントにはタブ文字（スペースではない）を使用し、 8 スペースごとにタブ ストップがあると想定します。
• 括弧のレイアウトは、K&R と一致し、開始と終了はそれぞれ別の行に配置され、複数のステートメントの開始は制御句と同じ行に配置され、スペースで区切られます。
• 文中のラベルはswitch囲んでいるブロックに合わせて配置されます（インデントは 1 レベルのみです）
• 行の最大文字数は100文字ですが、2020年以前の制限である80文字が推奨されます。^[14]
• 複合ステートメント (if、while、do-while など) の単一ステートメント本体は、中括弧で囲む必要はありません。ただし、ステートメント内の 1 つ以上のサブステートメントに中if-else括弧が必要な場合は、両方のサブステートメントを中括弧で囲む必要があります。

int累乗( int x 、int y ) { int結果;    

         

        if ( y < 0 ) { result = 0 ; } else { result = 1 ; while ( y -- > 0 ) result *= x ; } return result ; }    
                  
          
                  
                   
                          
        
         

Javaコードの大部分は、関数内のブロックだけでなく、クラスやメソッドの宣言でも開き中括弧が同じ行にあるK&Rスタイルのバリエーションを使用しています。このスタイルが広く普及しているのは、主にサン・マイクロシステムズのオリジナルのスタイルガイド^{[15] [16] [17]}がこのK&Rバリエーションを使用していたためであり、その結果、Java APIの標準ソースコードのほとんどはこのスタイルで書かれています。また、オールマンスタイルと並んで、 ActionScriptやJavaScriptのインデントスタイルとしても人気があります。

Bjarne Stroustrupは、著書『プログラミング：C++を使用した原則と実践』や『C++プログラミング言語』の中で、K&RスタイルをC++に取り入れました。^[18]

上記のバリエーションとは異なり、Stroustrupは「cuddled else」を使用していません。したがって、Stroustrupは次のように書きます^[18]

    if ( x < 0 ) { puts ( "負" ); negative ( x ); } else { puts ( "非負" ); nonnegative ( x ); }    
        
        
    
     
        
        
    

Stroustrup はクラスに対して K&R スタイルを拡張し、次のように記述します。

    class Vector { public : // Vector を構築 Vector ( int s ) : elem ( new double [ s ] ), sz ( s ) { } // 要素アクセス: 添字double & operator []( int i ) { return elem [ i ]; } int size () { return sz ; } private : // 要素へのポインタdouble * elem ; // 要素の数int sz ; };  
    
        
              
        
              
             
    
        
          
        
         
    

Stroustrup はラベルpublic:とをインデントしませんprivate:。また、このスタイルでは、関数の開き中括弧は新しい行から始まりますが、クラスの開き中括弧はクラス名と同じ行にあります。

Stroustrup は、短い関数をすべて 1 行に記述することを許可しています。Stroustrup スタイルは、 Emacsエディタで使用できる名前付きインデント スタイルです。Stroustrup は、最新のC++ Core Guidelinesで述べられているように、C++ で K&R 由来のスタイル レイアウトを推奨しています。^[19]

バークレーソフトウェアディストリビューション（BSD）オペレーティングシステムは、カーネル正規形（KNF）と呼ばれるスタイルを使用しています。主にカーネルコードを対象としていますが、ユーザーランドコードでも広く使用されています。これは本質的に、ベル研究所バージョン6および7のUnixソースコードで使用されているK＆Rスタイルの徹底的に文書化された変種です。^[20]

SunOSカーネルとユーザーランドは同様のインデントスタイルを使用しています。 [ ^{20 ]} KNFと同様に、これもAT&Tスタイルのドキュメントに基づいており、Bill Joy Normal Formと呼ばれることもあります。 [21] SunOSガイドラインは1996年に発行されました。ANSI Cについては簡単に説明されています。ソースファイルリストのインデントの正確さは、 Bill Shannonによって書かれたcstyleプログラムによって検証できます。^{[20] [21] [22]}

このスタイルでは、ハード タブ ( viの ts ) は 8 列に維持されますが、ソフト タブはヘルパーとして定義されることが多く (vi の sw)、4 列に設定されます。ハード タブはコード ブロックをインデントするために使用され、ソフト タブ (4 つのスペース) の追加インデントは、複数行に分割する必要があるすべての連続行に使用されます。

さらに、関数呼び出しでは括弧の前にスペースを使用しませんが、、、などの C 言語ネイティブ ステートメントではスペースをif使用します(括弧が使用されている場合)。最上位レベルのブロックでローカル変数を宣言しない関数も、開始ブロックの中括弧の後に空行を残す必要があります。 whiledoswitchreturnreturn

例:

while ( x == y ) { something (); something_else (); } final_thing ();    
        
        

if ( data != NULL && res > 0 ) { if ( JS_DefineProperty ( cx , o , "data" , STRING_TO_JSVAL ( JS_NewStringCopyN ( cx , data , res )), NULL , NULL , JSPROP_ENUMERATE ) != 0 ) { QUEUE_EXCEPTION ( "内部エラーです!" ); err に移動します。} PQfreemem ( data ); } else { if ( JS_DefineProperty ( cx , o , "data" , OBJECT_TO_JSVAL ( NULL ), NULL , NULL , JSPROP_ENUMERATE ) != 0 ) { QUEUE_EXCEPTION ( "内部エラーです!" ); errに移動します。} }        
           
              
                 
                
                 
        
        
  
            
                 
                
                 
        

静的JSBool pgresult_constructor ( JSContext * cx 、JSObject * obj 、uintN argc 、jsval * argv 、jsval * rval ) { 
     
       


        QUEUE_EXCEPTION ( "PGresult クラスはユーザーがインスタンス化できません" );

        戻り値( JS_FALSE ); } 

Allman スタイルはEric Allmanにちなんで名付けられました。AllmanはBSD Unix用のユーティリティを多数作成したため、BSD スタイルと呼ばれることもあります(ただし、これは別の「BSD KNF スタイル」と混同しないでください。上記を参照)。

このスタイルでは、制御文に関連付けられた中括弧を次の行に配置し、制御文と同じレベルにインデントします。中括弧内の文は次のレベルにインデントされます。^[12]

while ( x == y ) { something (); something_else (); }   

    
    


最終的なもの();

このスタイルは、 Pascal言語およびTransact-SQLで使用される標準のインデントに似ており、中括弧はキーワードbeginおよびに相当しますend。

(* Pascal の Allman コードのインデント スタイルの例 *) 
procedure dosomething ( x , y : Integer ) ; begin while x = y do begin something () ; something_else () ; end ; end ;   

        
    
        
        
    

このスタイルの結果、インデントされたコードは、ほとんどすべて空白の行によって、それを含むステートメントから明確に区別され、閉じ括弧は開き括弧と同じ列に並びます。これにより、対応する括弧が見つけやすくなると感じる人もいます。ブロッキング スタイルは、コード ブロックを関連する制御ステートメントから区別します。制御ステートメントまたはコード ブロックをコメント アウトまたは削除したり、コードをリファクタリングしたりすると、ぶら下がった括弧や欠落した括弧によって構文エラーが発生する可能性が低くなります。また、外側の関数ブロックの括弧の配置とも一貫性があります。

たとえば、次の文は構文的には正しいです。

// while (x == y) 
{ 
something (); something_else (); }    
    

以下も同様です:

// for (int i=0; i < x; i++) 
// while (x == y) 
if ( x == y ) { something (); something_else (); }   

    
    

条件付きコンパイルでは次のようになります:

    int c ; #ifdef HAS_GETCH while (( c = getch ()) != EOF ) #else while (( c = getchar ()) != EOF ) #endif { do_something ( c ); } 

         

         

    
        
    

Allman-8 は、Linux カーネルの K&R バリアントの 8 スペースのインデント タブと 80 列の制限を使用します。このスタイルは、プロジェクターでの可読性を向上させると言われています。また、インデントのサイズと列の制限により、コード ブロックの過剰なネストを識別するための視覚的な手がかりが作成されます。これらの利点を組み合わせることで、新しい開発者や学習者にコードの複雑さを管理するための暗黙のガイダンスを提供できます。^{[引用が必要]}

ホワイトスミス スタイル (ウィシャート スタイルとも呼ばれる) は、もともと最初の商用 C コンパイラであるホワイトスミスコンパイラのドキュメントで使用されていました。また、このスタイルは Windows の初期の頃にも人気があり、影響力のある 3 冊の Windows プログラミング ブック ( Durant、Carlson、Yao 著の『Programmer's Guide to Windows』 、 Petzold著の『Programming Windows』、Nortonおよび Yao著の『Windows 3.0 Power Programming Techniques』 ) で使用されていました。

1991年のジャーゴンファイルでは、ホワイトスミスとオールマンが最も一般的なブレーシングスタイルであり、当時はほぼ同等の人気を誇っていたと主張されていました。^{[12] [23]}

このスタイルでは、制御ステートメントに関連付けられた中括弧が次の行にインデントされて配置されます。中括弧内のステートメントは、中括弧と同じレベルにインデントされます。

ラトリフスタイルと同様に、閉じ括弧は括弧内の文と同じようにインデントされます。^[24]

while ( x == y ) { something (); something_else (); }   
    
    
    
    

最終的なもの();

このスタイルの利点は、Allman スタイルの利点に似ています。ブロックは制御ステートメントとは明確に区別されます。中括弧をブロックに揃えることで、ブロック全体が概念的にもプログラム的にも 1 つの複合ステートメントであることを強調します。中括弧をインデントすることで、中括弧が制御ステートメントに従属していることを強調します。終了中括弧はステートメントに揃うのではなく、開始中括弧に揃います。

例:

if ( data != NULL && res > 0 ) { if ( ! JS_DefineProperty ( cx , o , "data" , STRING_TO_JSVAL ( JS_NewStringCopyN ( cx , data , res )), NULL , NULL , JSPROP_ENUMERATE )) { QUEUE_EXCEPTION ( "内部エラーです!" ); err に移動します。} PQfreemem ( data ); } else if ( ! JS_DefineProperty ( cx , o , "data" , OBJECT_TO_JSVAL ( NULL ), NULL , NULL , JSPROP_ENUMERATE )) { QUEUE_EXCEPTION ( "内部エラーです!" ); errに移動します。}       
    
             
        
        
         
        
    
    
        
    
    
     
    

else ifプリプロセッサ ステートメントと同様に、ステートメントとして扱われます#elif。

オールマンスタイルやホワイトスミススタイルと同様に、GNUスタイルでは、関数定義の開始時を除いて、中括弧を2つのスペースでインデントして1行に置きます。関数定義の開始時にはインデントしません。^[25]どちらの場合でも、含まれるコードは中括弧から2つのスペースでインデントされます。

リチャード・ストールマンによって普及したレイアウトは、彼のLispコードを書く経歴に影響されているかもしれない。 ^[26] Lispでは、ブロックに相当するもの（progn）は第一級のデータエンティティであり、それに独自のインデントレベルを与えることでそれを強調するのに役立つが、Cではブロックは単なる構文である。このスタイルは、 1960年代と1970年代のALGOLとXPLプログラミング言語の教科書にも見られる。^{[27] [28] [議論]}

インデントそのものではありませんが、GNUコーディングスタイルでは関数名の後ろ、引数リストの左括弧の前にもスペースが入ります。^[25]

静的char * concat ( char * s1 、char * s2 ) { while ( x == y ) { something (); something_else (); } final_thing (); }  
    

     
    
       
       
    
   

このスタイルは、オールマンとホワイトスミスの利点を組み合わせたもので、ブレースがブロックから目立たないというホワイトスミスの欠点を解消しています。欠点の 1 つは、終了ブレースが、概念的に属するステートメントと一列に並ばなくなることです。もう 1 つの欠点は、1 つの概念レベルに 2 つの視覚的なインデント レベルを使用することでスペースを無駄にする可能性があることですが、実際には、単一レベルのインデントを使用するシステムでは、各レベルは通常、少なくとも 4 つのスペースであり、GNU スタイルの 2 * 2 スペースと同じであるため、このようなことは起こりそうにありません。

GNUコーディング標準ではこのスタイルが推奨されており、GNU プロジェクトソフトウェアのほぼすべてのメンテナーがこれを使用しています。^{[引用が必要]}

GNU EmacsテキストエディタとGNUシステムのインデントコマンドは、デフォルトでこのスタイルに従ってコードを再フォーマットします。^[29] GNU Emacsや同様の拡張/カスタマイズ可能なエディタを使用していない人は、エディタの自動インデント設定がこのスタイルには役に立たないことに気付くかもしれません。しかし、KNFスタイルをデフォルトとする多くのエディタは、タブ幅を2スペースに設定すればGNUスタイルにうまく対応します。同様に、GNU Emacsはタブ幅を8スペースに設定するだけでKNFスタイルにうまく適応します。どちらの場合も、自動再フォーマットにより元の間隔が破壊されますが、自動行インデントは適切に機能します。

スティーブ・マッコーネルは著書『Code Complete 』の中で、このスタイルの使用を勧めていない。マッコーネルは、このスタイルを使用しているコードサンプルに「Coding Horror」アイコンを付けて特に危険なコードを象徴し、可読性を損なうと述べている。^[24] Linuxカーネルのコーディングスタイルのドキュメントでもこのスタイルを推奨しておらず、読者に「偉大な象徴的なジェスチャー」としてGNUコーディング標準のコピーを焼き付けるよう促している。^[11]

Cay S. Horstmann著の1997年版Computing Concepts with C++ Essentialsでは、ブロックの最初の文を中括弧の先頭と同じ行に配置するというAllmanのスタイルを採用しています。このスタイルは、JensenとWirthのPascal User Manual and Reportの例でも使用されています。^[30]

while ( x == y ) { something (); something_else (); //... if ( x < 0 ) { printf ( "負" ); negative ( x ); } else { printf ( "非負" ); nonnegative ( x ); } } final_thing ();   
   
    
    
       
       
        
    
    
       
        
    

このスタイルは、可読性のために中括弧の垂直配置を維持し、ブロックを簡単に識別できるというオールマンの利点と、K＆Rスタイルの行を節約する利点を兼ね備えています。ただし、2003年版では、オールマンスタイルが全面的に使用されています。^[31]

これは、言語Picoの設計者によって最も一般的に使用されているスタイルです。Picoにはreturn文がなく、文の区切りとしてセミコロンを終端文字の代わりに使用します。その結果、次の構文が得られます。^[32]

もの(名詞):
{ x: 3 * n;
  y: do_stuff(x);
  y + x }

利点と欠点は、K&R スタイルで画面領域を節約する場合と同様です。追加の利点は、開始中括弧と終了中括弧の適用が一貫している (両方ともコード行とスペースを共有) ことです。これは、1 つの中括弧がコード行とスペースを共有し、もう 1 つの中括弧が 1 行だけを占める K&R スタイルと比較して、同じです。

Programmers at Work という書籍で、 ^{[33]人気の高い}第四世代プログラミング言語dBase -II および -III の元祖プログラマである C. Wayne Ratliff は、1TBS に似ているが閉じ括弧がネストされたブロックのインデントと揃うスタイルについて論じています。彼は、このスタイルがもともとDigital Research Inc. の資料で文書化されたものであると述べています。このスタイルは、おそらくポールから垂れ下がったバナーに似ていることから、バナースタイルと呼ばれることもあります^[34]。Whitesmiths にとっての K&R が Allman にとってであるのと同じように、このスタイルでは、閉じ括弧はリストの最後の項目と同じようにインデントされます (したがって、適切に重要性を失います) ^[24]このスタイルにより、視覚的なスキャンが容易になります。これは、ブロックのヘッダーがそのレベルで拡張される唯一のものであるためです (K&R および Allman スタイルでは、前のブロックの閉じ括弧が次のブロック ヘッダーの視覚的な流れを妨げるという理論に基づいています)。カーニハンとプラウガーは、ソフトウェアツールのRatforコードでこのスタイルを使用しています。^[35]

 // C の場合
for ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 == 0 ) { do_something ( i ); } else { do_something_else ( i ); } }         
           
         
         
      
         
         
     

以下のスタイルは、C から派生したさまざまな言語に共通しており、非常に類似している点と非常に異なる点があります。また、C にも適用できます。主に他の言語のいずれかで記述されたプロジェクトの一部として記述された C コードに適用できます。この場合、プロジェクトのコア コードの一貫した外観と操作性を維持することが、より一般的な C スタイルの使用よりも優先されます。

GNU スタイルは、Lisp プログラマーによってインデントされた C コードとして特徴付けられることもありますが、ブロックの最後の行に閉じ括弧を挿入することもあります。このスタイルでは、インデントがコード ブロックを区別する唯一の方法になりますが、情報のない行が含まれないという利点があります。このスタイルは Lisp コードで非常に一般的なので、簡単に Lisp スタイルと呼ぶことができます。Lisp では、式ツリーの最後に同じ括弧をグループ化することは、ネスト レベルを視覚的に追跡することがユーザーの仕事ではなく、ツリーの構造を理解することだけであることを示すためのものです。

このスタイルの従来の Lisp バリアントでは、非常に狭いレベルのインデント (通常は 2 つのスペース) が好まれます。これは、Lispには明確な文のクラスがなく、式のみが用意されているため、Lisp コードは通常非常に深くネストされるためです。関数の引数は、ほとんどの場合、囲んでいる式内での共有ステータスを示すために同じレベルにインデントされます。これは、中括弧は別として、Lisp が伝統的に非常に簡潔な言語であるためでもあり、ブロック内のキーワードなどの単純な定型コードの一般的な形式でさえ、情報量が不十分なため省略し、代わりに一律に としてレンダリングします。 elseif : then | else(if expr1 expr2 expr3)

// C 
for ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 == 0 ) { do_something ( i );} else { do_something_else ( i ); do_third_thing ( i );}}       
         
        
     
        
         

;; Lisp 
( dotimes ( i 10 ) ( if ( = ( rem i 2 ) 0 ) ( do-something i ) ( progn ( do-something-else i ) ( do-third-thing i ))))  
       
       
    
       
       

^{注: は、最終 (n 番目) の戻り値以外をすべて破棄しながら、効果prognに対して複数の部分式を順番に評価する手順です。すべての戻り値が必要な場合は、この手順が使用されます。values}

Haskellのレイアウトでは中括弧の配置をオプションにすることができますが、言語では中括弧とセミコロンが許可されています。 ^[36] 以下の2つのセグメントは、コンパイラーにとって同様に受け入れられます。

braceless = do text <- getContents let firstWord = head $ words text bigWord = map toUpper firstWord putStrLn bigWord  
    
  
         
        
   

braceful = do { text <- getContents ; let { firstWord = head $ words text ; bigWord = map toUpper firstWord } ; putStrLn bigWord }  
     
   
            
           
      
    
  

Haskellでは、レイアウトは中括弧の代わりに使用できます。通常、中括弧とセミコロンは手続き do部やプログラムテキスト全体では省略されますが、このスタイルは、カンマやセミコロンで区切られた括弧や中括弧のペアで構成されるリスト、レコード、その他の構文要素によく使用されます。^[37]キーワードwhere、、letまたはに続くコードで中of括弧とセミコロンが省略されている場合、インデントが重要になります。^[38]

APL がいかに簡潔であるかの例として、ライフ ゲームのステップ関数の実装を次に示します。

人生← { ⊃ 1 ⍵ ∨ . ∧ 3 4 =+ / + ⌿ ¯1 0 1 ∘. ⊖ ¯1 0 1 ⌽ ¨ ⊂ ⍵ }     

APLスタイルのCはAPLコードの簡潔なスタイルに似ており、その実装でよく使用されています。^{[39]このスタイルは}アーサー・ホイットニーによって開拓され、アーサー自身のプロジェクトであるKの実装で頻繁に使用されています。Jプログラミング言語もこのスタイルで実装されています。注目すべきは、APLのすべての実装がこのCスタイルを使用しているわけではないことです。具体的には、GNU APLとDyalog APLです。

APLスタイルのCインデントに加えて、通常、名前は1文字または2文字に短縮されます。インデントの量を減らし、複数行にまたがる式を減らすためです。^[40]

通常、プログラマーは、同じ幅の空白を使用して各コード ブロックをインデントします。一般的に使用される幅は 1 ～ 4 スペースです。

1983年にPASCALコードで行われた実験では、インデントのサイズが理解度に大きな影響を与えることが判明しました。2文字から4文字のインデントのサイズが最適であることが証明されました。^[41]

どちらもコードの全体的なレイアウトに影響しますが、インデントのサイズはここで説明するインデントスタイルとは無関係です。

通常、プログラマーは、スタイルに従って空白を維持するために、固定間隔 (スペースの数) でタブ ストップを提供するテキスト エディターを使用します。この間隔は、タブ幅と呼ばれます。プログラマーは、タブ キーを押すたびに 1 つのタブ文字を含むコードを保存する場合もあれば、タブ幅と同じ数のスペースのシーケンスを保存する場合もあります。

コード内にタブ文字を保存すると、異なるコンテキストで表示したときに視覚的なずれが生じる可能性があり、インデント スタイルの価値が損なわれます。

プログラマーの間ではタブ文字の保存に関するコンセンサスが得られていません。タブ文字の保存を支持する人は、1つのタブ文字が複数のスペースの役割を果たすため、入力が簡単でテキストファイルが小さくなると言います。ジェイミー・ザウィンスキーなどの反対派は、代わりにスペースを使用するとクロスプラットフォームの移植 性が向上すると主張しています。 ^[42] WordPressコーディング標準の作成者などの他の人は、その逆で、ハードタブが移植性を高めると主張しています。^[43] GitHubの上位40万のリポジトリを調査したところ、スペースの方が一般的であることがわかりました。^[44]

Notepad++、TextEdit、Emacs、vi、nanoなどの多くのテキスト エディターは、Tab キーで入力されたときにタブ文字を保存するか、またはタブ文字をスペースに変換する (構成されたタブ幅に基づく) ように設定できます。これにより、Tab キーが押されたときにタブ文字がファイルに追加されなくなります。エディターによっては、タブをスペース文字に変換したり、その逆を行ったりできます。

lessなどの一部のテキスト ファイル ページャーでは、タブ幅を設定できます。expand / unexpandなどの一部のツールでは、フィルターを使用してオンザフライで変換できます。

ツールを使用すると、 Unix コマンドなどのインデント スタイルに従ってコードの書式設定を自動化できますindent。

Emacs には、Tab特定の行をヒットするなど、インデントを変更するコマンドが用意されています。M-x indent-regionコードをインデントします。

エラスティック タブストップは、テキスト エディターのサポートを必要とするタブ形式です。ブロック内の 1 行の長さが変わっても、テキスト ブロック全体の位置が自動的に揃えられます。

より複雑なコードでは、プログラマーはコードを読んでいるときにブロックの境界を見失うことがあります。これは、多くのインデント レベルにネストされた多数の複合ステートメントを含むコードの大きなセクションでよく発生します。プログラマーがネストされたステートメントの膨大なセットの一番下までスクロールすると、ブロックの先頭にある制御構造などのコンテキストを見失うことがあります。

長い複合文は、過度に複雑であるというコードの臭いになる可能性がありますが、これはリファクタリングによって解決できます。

開き中括弧の数を数えることに頼っているプログラマーは、開き中括弧が制御文から視覚的に分離されていないK&R などのインデント スタイルで苦労するかもしれません。インデントに頼るプログラマーは、ブロックが短いため、K&R などの垂直方向にコンパクトなスタイルからより多くの恩恵を受けるでしょう。

などの制御文を見失うことを避けるためにfor、8 単位幅のハード タブなどの大きなインデントを使用し、大きな関数をより小さく読みやすい関数に分割することができます。Linux では、K&R スタイルを使用してこの方法が採用されています。

一部のテキストエディタでは、プログラマがブロックの対応する2つの括弧間を移動することができます。たとえば、viは、キーを押すと、カーソルの下にあるブロックと同じブロックを囲む括弧にジャンプします%。テキストカーソルのnextキー（つまり、nキー）は方向の位置情報（キーupまたはdownキーが以前に押されたかどうか）を保持しているため、ドットマクロ（.キー）を使用して、テキストカーソルを次の括弧に配置することができます^[45]。代わりに、キーを使用してブロックの境界を検査することで%、コーディング標準を強制することができます。

ブロック認識を維持するもう 1 つの方法は、閉じ括弧の後にコメントを使用することです。例:

for ( int i = 0 ; i < total ; i ++ ) { foo (); } // for (i)         
    
 

if ( x < 0 ) { bar (); } //if (x < 0)    
   
 

欠点は、ブロックの上と下の複数の場所で同じコードを維持することです。

一部のエディターでは、ブロック認識の維持がサポートされています。折りたたみエディターでは、インデント レベルによってブロックを非表示 (折りたたむ) したり、表示 (展開) したりできます。一部のエディターでは、カーソルが中括弧の横にある ときに、対応する中括弧が強調表示されます。

K&R スタイルは、制御文の後、つまり開き括弧の前にコード行を挿入することによって発生する一般的なエラーを防止します。挿入された行によって、ブロックは制御文から切り離されます。

次の開始コードがあるとします:

for ( int i = 0 ; i < 10 ; i ++ ) { do_something (); } // for (i)        

    
 

do_something10 回呼び出されます。次に、新しい 2 行目を追加して変更します。

( int i = 0 ; i < 10 ; i ++ )の場合        
    何か他のことを行う();
{
    do_something (); // 一度呼び出されます! 
} // (i) の場合 

元のブロック (3 行目から 5 行目) はループ本体ではなくなりfor、1 回だけ実行されます。さらに、5 行目のコメントが間違っています。

K&R スタイルでは、制御ステートメントと開き中括弧を同じ行に置くことでこの問題を回避します。

オリジナル：

( int i = 0 ; i < 10 ; i ++ ) {​         
    何かを行う();
} // (i) の場合 

新しい 2 行目を追加しても、呼び出される回数do_somethingや終了コメントの有効性には影響しません。

( int i = 0 ; i < 10 ; i ++ ) {​         
    何か他のことを行う();
    何かを行う();
} // (i) の場合 

• 二次表記
• 構文の強調表示
• インデント（タイプセッティング） § プログラミングにおけるインデント
• シリコンバレーのエピソード「バクマニティ・インサニティ」でこのテーマを取り上げている
• ソースコードフォーマッタ

• C スタイル: 標準とガイドライン: プロフェッショナル C プログラマー向けのプログラミング標準の定義、Prentice Hall、ISBN 0-13-116898-3 / ISBN 978-0-13-116898-5 (全文はオンラインでも入手可能)。Straker、David (1992)。  
• コンテキストインデント
• GNU コーディング標準

• タブ対スペース: 永遠の聖戦 (ジェイミー・ザウィンスキー著)
• ソースコードにタブを使わない方が良い理由 (Adam Spiers 著)
• ソースコードにタブを付けるのが大好きな理由 (アーカイブ)
• 伸縮自在のタブストップ – タブとスペースの問題に対する解決策