単一行のifまたはループに中括弧（つまり{}）を使用する目的は何ですか？

私は私のC ++講師の講義ノートをいくつか読んでいます、そして彼は以下を書きました：

1. インデントを使用// OK
2. 演算子の優先順位に依存しない-常に括弧を使用する// OK
3. 常に{}ブロックを使用します-1 行の場合でも// OKではありません。なぜですか???
4. 比較の左側にあるConstオブジェクト// OK
5. > = 0の変数には符号なしを使用します//素敵なトリック
6. 削除後にポインターをNULLに設定-二重削除保護//悪くない

3番目の手法は私にははっきりしていません。1つの行を{ ... }？

たとえば、次の奇妙なコードを見てください。

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

そしてそれを次のものに置き換えます：

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

最初のバージョンを使用する利点は何ですか？

iインクリメントするときにも変更してみましょうj：

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

大野！Pythonから来た場合、これは問題ないように見えますが、実際にはそうではありません。

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

もちろん、これはばかげた間違いですが、経験豊富なプログラマでさえも起こり得る間違いです。

別の非常に良い理由は、ta.speot.isの回答で指摘されています。

私が考えることができる3番目のものは入れ子ifのものです：

if (cond1)
   if (cond2) 
      doSomething();

さて、あなたが今会いたくないdoSomethingElse()ときにしたいと思いますcond1（新機能）。そう：

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

これ以降、明らかに間違っているelse、内側に関連付けますif。

編集：これは注目を集めているので、私の見方を明確にします。私が答えていた質問は：

最初のバージョンを使用する利点は何ですか？

私が説明した。いくつかの利点があります。ただし、IMOの「常に」のルールは常に適用されるわけではありません。だから私は完全にサポートしていません

常に{}ブロックを使用します-1行でも// OKではありません。なぜですか???

いつも{}ブロックを使うと言っているのではありません。それが十分に単純な条件と振る舞いであるなら、そうしないでください。誰かが後で来るかもしれないと疑い、機能を追加するようにコードを変更する場合は、実行してください。

{andを使用しない場合、コメントを使用して制御フローを誤って変更することは非常に簡単です}。例えば：

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

あなたがコメントアウト場合はdo_something_else()1行コメントで、あなたはこれで終わるだろう：

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

コンパイルされますが、must_always_do_this()常に呼び出されるわけではありません。

コードベースにこの問題があり、リリース前に誰かが一部の機能を非常に早く無効にしていた。幸い、私たちはコードレビューでそれを見つけました。

講師の能力に疑問があります。彼のポイントを考慮して：

1. OK
2. 誰かが本当に書いたり（または読みたい）(b*b) - ((4*a)*c)でしょうか？いくつかの優先順位は明らかであり（またはそうである必要があります）、余分な括弧は混乱を増すだけです。（一方、括弧が不要であることを知っていても、あまり明確でない場合は括弧を使用する必要があります）。
3. ちょっと。条件文とループの書式設定には、2つの広義の規則があります。

   if（cond）{
       コード;
   }
   

   そして：

   if（cond）
   {
       コード;
   }
   

   最初に、私は彼に同意します。開口部{はそれほど見えないので、常にそこにあると想定するのが最善です。ただし、2番目の方法では、私（およびこれまでに作業したほとんどの人々）は、単一のステートメントで中括弧を省略しても問題はありません。（もちろん、インデントが体系的であり、このスタイルを一貫して使用していることを前提としています（そして、非常に読みやすいコードを記述している多くの非常に優れたプログラマーは、最初の方法でフォーマットする場合でも中括弧を省略します）。
4. いいえ。のようなものif ( NULL == ptr )は読みにくくなるほど醜いです。比較を直感的に記述します。（多くの場合、結果は右側の定数になります。）彼の4は悪いアドバイスです。コードが不自然になると、コードが読みにくくなります。
5. いいえ。何もなく、はint、特別な場合のために予約されています。経験豊富なCおよびC ++プログラマにとって、unsignedシグナルビット演算子の使用。C ++には実際の基本型（または他の有効な部分範囲型）はありません。unsignedプロモーションルールのため、数値では機能しません。シリアル番号のように、算術演算が意味をなさない数値は、おそらくですunsigned。ただし、これは間違ったメッセージを送信するため、これには反対です。ビット単位の演算も意味がありません。基本的な規則は、整数型はintであるということです。ただし、別の型を使用する重要な理由はありません。
6. いいえ。これを体系的に行うことは誤解を招きやすく、実際には何も保護しません。厳密なOOコードでdelete this;は、これが最も頻繁に発生します（そしてに設定thisすることはできませんNULL）。それ以外の場合、ほとんどdeleteがデストラクターにあるため、後でポインターにアクセスできません。そして、それを設定することNULLは、周りに浮かんでいる他のいかなるポインタについても何もしません。体系的にポインターを設定するとNULL、誤った安心感が与えられ、実際には何も購入されません。

典型的な参考文献のコードを見てください。たとえば、Stroustrupは最初のルールを除いて、指定したすべてのルールに違反します。

別の講師を見つけることをお勧めします。彼が話していることを実際に知っている人。

他のすべての回答は、講師のルールを守ります3。

私はあなたに同意すると言いましょう：ルールは冗長であり、私はそれを助言しません。それは、それが本当だ理論的に常に中かっこを追加するはエラーを防ぐことができます。一方、私は実際にこの問題に遭遇したことはありません。他の答えが意味するところとは逆に、中括弧が必要になったときに、中括弧を追加するのを忘れたことはありません。適切なインデントを使用すると、複数のステートメントがインデントされた後に中括弧を追加する必要があることがすぐに明らかになります。

「コンポーネント10」による回答は、実際にこれが本当にエラーにつながる可能性のある唯一の考えられるケースを強調しています。しかしその一方で、正規表現を使用してコードを置き換えると、とにかく常に細心の注意が必要になります。

メダルの反対側を見てみましょう：中括弧を常に使用することには不利な点がありますか？他の答えは単にこの点を無視します。しかし、そこにあります短所：それは垂直方向の画面スペースの多くを占めており、それはあなたが必要以上にスクロールしなければならないことを意味するので、これは順番に、あなたのコードが読めなくすることができます。

最初に多くのガード句がある関数を考えてください（そうです、以下は悪いC ++コードですが、他の言語ではこれはかなり一般的な状況です）：

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

これは恐ろしいコードであり、以下の方がはるかに読みやすいと強く主張します。

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

同様に、入れ子にされた短いループは、中括弧を省略することでメリットを得られます。

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

と比べて：

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

最初のコードは簡潔です。2番目のコードは肥大化しています。

そして、はい、これは前の行に開始中かっこを置くことである程度緩和できます。しかし、それでも、中括弧がないコードよりも読みにくくなります。

つまり、画面スペースを占有する不要なコードを記述しないでください。

私が取り組んでいるコードベースは、中かっこに病的な嫌悪感を抱く人々によってコードが散らばっています。後に来る人々にとって、それは本当に保守性に違いをもたらすことができます。

私が遭遇した最も頻繁な問題のある例はこれです：

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

したがって、私が来て、thenステートメントを追加したい場合、注意しなければ、簡単にこれで終了してしまいます。

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

中かっこを追加するのに最大1秒かかり、少なくとも数分の混乱したデバッグを節約できるとすれば、あいまいさを減らしたオプションを使用しないのはなぜですか？私には偽の経済のようです。

私の2c：

インデントを使用する

明らかに

演算子の優先順位に依存しない-常に括弧を使用する

私は「決して」と「常に」という言葉は使用しませんが、一般的にはこのルールが役立つと思います一部の言語（Lisp、Smalltalk）では、これは問題ではありません。

常に{}ブロックを使用します-1行の場合でも

私はそれをしたことはなく、単一の問題を抱えたことはありませんが、それが生徒にとってどのように役立つかを見ることができます。彼らが以前にPythonを勉強した場合。

比較の左側にあるconstオブジェクト

依田状態？いいえ、お願いします。読みやすさが損なわれます。コードをコンパイルするときは、最大警告レベルを使用してください。

0以上の変数には符号なしを使用します

OK。面白いことに、Stroustrupが反対することを聞いたことがあります。

削除後にポインターをNULLに設定-二重削除保護

悪いアドバイス！削除されたオブジェクトまたは存在しないオブジェクトを指すポインターは決してありません。

より直感的で簡単に理解できます。それは意図を明確にします。

そしてそれは、新しいユーザーが知らないうちに逃す可能性がある場合、コードが破損しないことを保証し{、}新しいコードのステートメントを追加しています。

上記の非常に賢明な提案に追加して、これが重要になる場所のいくつかのコードをリファクタリングしているときに遭遇した1つの例は次のとおりです。最初のAPIには、会社IDを次のように設定する呼び出しがありました。

setCompIds( const std::string& compId, const std::string& compSubId );

一方、置換には2つの呼び出しが必要でした。

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

非常に成功した正規表現を使用してこれを変更することにしました。また、コードをastyleに渡しました。これにより、コードが非常に読みやすくなりました。次に、レビュープロセスの途中で、一部の条件付きの状況では、これを変更していることがわかりました。

if ( condition )
   setCompIds( compId, compSubId );

これに：

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

これは明らかに必要なものではありません。私は最初に戻ってこれをやり直して、置換を完全にブロック内として扱い、最終的に間抜けに見えたものを手動で変更する必要がありました（少なくともそれは正しくありません）。

astyleには--add-bracketsブラケットがない場合にブラケットを追加できるオプションがあることに気づきました。私と同じ位置にいる場合は、これを強くお勧めします。

{}明らかな場合を除いて、どこでも使用しています。単一行は次のいずれかの場合です。

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

戻る前にメソッドを追加すると、害を及ぼす可能性があります。インデントは、条件が満たされたときにリターンが実行されていることを示しますが、常にリターンします。

ステートメントを使用したC＃の他の例

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

これは

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

私が考えることができる最も適切な例：

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

どちらifとelseペアになりますか？インデントは、アウターifがを取得することを意味しelseますが、コンパイラーが実際にそれを認識する方法ではありません。内側の ifでしょうelse、と外ifありません。このコードがなぜあなたの期待に反しているのかを調べて理解するには、それを知っている必要があります（またはデバッグモードでそのように動作することを確認してください）。Pythonを知っていると、さらに混乱します。その場合、インデントはコードブロックを定義することがわかっているので、インデントに従って評価することが期待されます。ただし、C＃は空白について空中フリップを行いません。

とはいえ、この「常に角かっこを使用する」というルールには特に同意しません。これにより、コードが垂直方向に非常にノイズが多くなり、コードをすばやく読み取ることができなくなります。ステートメントが次の場合：

if(someCondition)
   DoSomething();

...それはこのように書かれるべきです。「常に角かっこを使用する」という文は、「常に算術演算を括弧で囲む」のように聞こえます。それは非常に単純なステートメントをにa * b + c / d変え((a * b) + (c / d))、閉じかっこ（多くのコーダーの悩みの種）を見逃す可能性を導入し、何のために？操作の順序はよく知られており、強化されているため、括弧は冗長です。a * (b+c) / dたとえば、通常適用されるのとは異なる操作の順序を強制するために、括弧のみを使用します。ブロックブレースも同様です。これらを使用して、デフォルトとは異なり、「自明」ではない（主観的ですが、通常はかなり常識）場合に何をしたいかを定義します。

答えを調べて、私が習慣とする種類の習慣を明確に述べていないのは、あなたのコードの物語です。

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

になる：

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

パッティングj++に同じ行誰にも知らせる必要があるかのように、「私は今までインクリメントにこのブロックをしたいですj」。もちろん、これは、行が可能な限り単純化されている場合にのみ価値があります。ペリに言及されているように、ここにブレークポイントを置くことはあまり役に立ちません。

実際、私はJavaでこの「ソート」されたコードを持つTwitter Storm APIの一部に出くわしました。このスライドショーの43ページに、実行コードからの関連するスニペットがあります。

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

forループブロックには2つのものが含まれているため、そのコードをインライン化しません。すなわち決して：

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

それはひどいですし、それが（意図したとおりに）機能するかどうかさえわかりません。これを行わないでください。新しい行と中括弧は、散文でコンマまたはセミコロンが行うのと同じように、関連している別々のコードを区別するのに役立ちます。上記のブロックは、いくつかの句と、別の部分を区別するために中断または一時停止しないいくつかの他のステートメントを含む非常に長い文と同じくらい悪いです。

あなたが本当に誰かに電報を送りたいなら、それは一行のみの仕事であり、三項演算子または?:フォームを使います：

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

しかし、これはコードゴルフに近づきつつあり、私は素晴らしい習慣ではないと思います（私がj ++を片側に置くべきかどうかは私には明確ではあり:ません）。注意： C ++で三項演算子を実行したことがないので、これが機能するかどうかはわかりませんが、存在します。

要するに：

読者（つまり、コードを保守している人）があなたのストーリー（コード）をどのように解釈するか想像してみてください。それらをできるだけ明確にします。初心者のコーダー/学生がこれを維持していることを知っている場合{}は、混乱しないように、できるだけ多くを残しておいてください。

せず{}に2つのステートメントがある場合、問題を見逃しがちです。コードが次のようになっているとします。

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

元気そうです。特にコードを含む関数がはるかに大きい場合、この問題は見逃しがちです。問題は、goto fail無条件に実行されることです。これがどれほど苛立たしいかは簡単に想像できます（hash_updateすべてにおいてhash_update機能上問題がないように見えた後、lastが常に失敗する理由を尋ねます）。

しかし、それは私が{}どこにでも追加することを意味するわけではありません（私の意見では、{}どこでも見るのは面倒です）。問題が発生する可能性はありますが、私の個人のコーディングスタイルでは条件{}が同じ行にない場合を除いて禁止されているため、自分のプロジェクトでは発生しませんでした（そうです、私のコーディングスタイルは型破りであることに同意しますが、私は気に入っています。他のプロジェクトに貢献するときは、プロジェクトのコードスタイルを使用します）。これにより、次のコードが正常になります。

if (something) goto fail;

しかし、次のものではありません。

if (something)
    goto fail;

ループと条件付きブロックのスコープを明確に定義することで、コードを読みやすくします。また、偶発的なミスからあなたを救います。

wrt 6：nullポインタの削除は何もしないので、より安全です。したがって、偶然にそのパスを2度通過しても、メモリ破損が原因で、解放されているメモリまたは別のメモリに割り当てられているメモリが解放されることはありません。

これは、存続期間が明確ではなく、破棄された後に再作成されることが知られている静的ファイルスコープオブジェクトとシングルトンの問題のほとんどです。

ほとんどの場合、auto_ptrsを使用することで、この必要性を回避できます。

私はルチアンの受け入れられた答えが好きです。実際、彼が正しいことを難しい方法で学んだので、単一行のブロックであっても、常に中括弧を使用します。ただし、あなたの例のように、個人的にはフィルターを作成するときに例外を設けています。この：

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

乱雑に見えます。これは、forループとifステートメントを別々のアクションに分離しますが、実際の目的は単一のアクションです。2で割り切れる整数をすべてカウントするためです。より表現力豊かな言語では、次のように記述できます。

j = [1..100].filter(_%2 == 0).Count

クロージャーがない言語では、フィルターを単一のステートメントで表現することはできませんが、forループの後にifステートメントを続ける必要があります。しかし、それはまだプログラマーの頭の中の1つのアクションであり、私はそれをコードに反映する必要があると信じています。

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

上で説明したエラーの防止に役立つオプションの1つは、中括弧を使用しない場合に何をしたいかをインライン化することです。コードを変更しようとすると、エラーに気付かないようにするのがはるかに難しくなります。

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

あなたがコンパイラーなら、それは何の違いもありません。どちらも同じです。

しかし、プログラマーにとっては、最初のものはより明確で読みやすく、エラーが起こりにくいものです。

中括弧を追加する別の例。バグを検索してそのようなコードを見つけたら：

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

メソッドを1行ずつ読むと、メソッドにtrueでない場合に返される条件があることがわかります。しかし、実際には、いくつかの条件に基づいていくつかの変数を設定する100の他の単純なイベントハンドラーのように見えます。そしてある日、Fast Coderが登場し、メソッドの最後に変数設定ステートメントを追加します。

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

その結果、SomeAnditionIsMet（）の実行時にSetAnotherVariableUnconditionnalyが実行されますが、すべての行のサイズがほぼ同じであり、戻り条件が垂直にインデントされていてもそれほど目立たないため、高速な人はそれに気付きませんでした。

条件付き戻りが次のようにフォーマットされている場合：

if (!SomeConditionIsMet())
{
    return;
}

それは非常に目立ち、Fast Coderは一目でそれを見つけます。

私は最初のものを明確にし、次に2番目のものを考える。これは、与えたコードが複雑になったときに少しのコードで、指示を閉じる感は結構です{...}、それであっても多くのことができますendifかbegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

使い終わったら、ポインタをNULLに設定することをお勧めします。

理由は次のとおりです。

クラスAは次のことを行います。

1. メモリのブロックを割り当てます
2. その後、しばらくすると、このメモリブロックが削除されますが、ポインタはNULLに設定されません。

クラスBは次のことを行います

1. メモリを割り当てます（この場合、クラスAによって削除されたのと同じメモリブロックが割り当てられます）。

この時点で、クラスAとクラスBの両方に同じメモリブロックを指すポインタがありますが、クラスAに関する限り、このメモリブロックは終了しているため存在しません。

次の問題を検討してください。

クラスAに論理エラーがあり、その結果、クラスBに属するメモリに書き込まれた場合はどうなりますか？

この特定のインスタンスでは、クラスAがクラスBのデータを事実上破壊している間、メモリアドレスは有効であるため、不良アクセス例外エラーは発生しません。

クラスBは、予期しない値に遭遇すると最終的にクラッシュする可能性があり、クラッシュした場合、問題がクラスAにあるときに、クラスBでこのバグの検出にかなりの時間を費やすことになります。

削除されたメモリポインタをNULLに設定した場合、クラスAの論理エラーがNULLポインタに書き込もうとするとすぐに例外エラーが発生します。

ポインタが2度目にNULLになったときに、二重削除による論理エラーが心配な場合は、これにアサートを追加します。

また、反対票を投じる場合は説明してください。

常に中かっこを付けることは、非常にシンプルで堅牢なルールです。ただし、中括弧が多い場合、コードは洗練されていないように見えます。ルールで中括弧を省略できる場合は、より詳細なスタイルルールとより高度なツールが必要です。そうしないと、混乱して混乱する（エレガントではない）コードが簡単に発生する可能性があります。したがって、使用されている他のスタイルガイドやツールとは別の単一のスタイルルールを見ても効果がない可能性があります。他の回答では言及されていない、ルール3に関する重要な詳細をいくつか紹介します。

最初の興味深い詳細は、そのルールのほとんどの支持者がの場合にそれに違反することに同意することですelse。言い換えれば、彼らはレビューでそのようなコードを要求しません：

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

代わりに、彼らがそれを見る場合、彼らはそのようにそれを書くことさえ提案するかもしれません：

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

elseとの間に中括弧がないため、これは技術的にはこの規則の違反ですif。このようなルールの二重性は、マインドレスなツールを使用してコードベースに自動的に適用しようとするときに表面化します。確かに、なぜ論争するのか、スタイルを自動的に適用するツールを使用してください。

2番目の詳細（これもそのルールの支持者によって忘れられることが多い）は、発生する可能性のあるエラーは、そのルール＃3の違反のためだけではないということです。実際、それらはほとんど常にルール＃1の違反を伴います（誰も議論しません）。自動ツールの観点からも、ルール＃1に違反するとすぐに文句を言うツールを作成することは難しくないため、ほとんどのエラーをタイムリーにキャッチできます。

3番目の詳細（そのルールの反対者がしばしば忘れる）は、単一のセミコロンで表される空のステートメントの混乱する性質です。ある程度の経験を持つほとんどの開発者は、セミコロンを間違って配置したり、セミコロンを1つ使用して記述された空のステートメントによって遅かれ早かれ混乱したりしました。1つのセミコロンの代わりに2つの中括弧を使用すると、視覚的に見つけやすくなります。

常に{}1行で使用するわけではないことを認めなければなりませんが、それは良い習慣です。

• 次のような括弧なしのコードを書いたとします。

  for（int i = 0; i <100; ++ i）for（int j = 0; j <100; ++ j）DoSingleStuff（）;

しばらくしてから、jループに他の要素を追加したいのですが、アラインメントでそれを行い、ブラケットを追加するのを忘れます。

• メモリの割り当て解除が高速です。あなたは大きなスコープを持っていて、内部に大きな配列を作成するとしましょう（newそうしないとそれらはスタックになります）。これらの配列は、スコープを離れた直後にメモリから削除されます。ただし、その配列を1か所で使用すると、しばらくの間スタックになり、ある種のゴミになる可能性があります。スタックには制限があり、サイズが非常に小さいため、スタックサイズを超える可能性があります。ですから、それ{}を防ぐために書く方が良い場合もあります。注：これは1行ではなく、そのような状況用です。

  if（...）{// SomeStuff ... {// if、whileなどはありません。// SomeOtherStuff} // SomeMoreStuff}

• それを使用する3番目の方法は2番目と同様です。それは単にスタックをきれいにするためではなく、いくつかの関数を開くためです。mutex通常、長い関数で使用する場合は、データにアクセスする直前と、データの読み取り/書き込みを完了した直後に、ロックとロック解除を行うことをお勧めします。NOTEあなたには、いくつかの独自のを持っている場合は、この方法が使用されclassたりstructしてconstructorとdestructorロックメモリに。

• さらに何が：

  if（...）if（...）SomeStuff（）; else SomeOtherStuff（）; // 2番目のifに移動しますが、最初はオンになっていることが示されます...

オールインオール、私は言うことはできません、常に{}単一の行に使用するための最良の方法は何ですか？それは悪いことではありません。

重要な編集 1行のコンパイルコードブ​​ラケットを記述しても何も起こりませんが、コードが解釈されると、コードの速度が非常に遅くなります。ほんの少し。

制御ステートメントを書く方法はいくつかあります。それらの特定の組み合わせは、読みやすさを損なうことなく共存できますが、他の組み合わせは問題を引き起こします。スタイル

if (condition)
  statement;

は、制御ステートメントを記述する他のいくつかの方法と快適に共存しますが、他の方法とはあまりうまく共存しません。複数行の制御ステートメントが次のように記述されている場合：

if (condition)
{
  statement;
  statement;
}

次に、どのifステートメントが単一行を制御し、どのステートメントが複数行を制御するかが視覚的に明らかになります。ただし、複数行のifステートメントが次のように記述されている場合：

if (condition) {
  statement;
  statement;
}

その場合、誰かifが必要な中括弧を追加せずに単一ステートメント構成を拡張しようとする可能性ははるかに高くなる可能性があります。

ifコードベースがフォームを大幅に使用する場合、次の単一ステートメントの次のステートメントも問題になる可能性があります。

if (condition) statement;

私自身の好みは、if同じ行にステートメントを置くことで、同様の制御ブロックを持つ多くのステートメントがある場合を除いて、一般的に読みやすさが向上することです。

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

その場合、一般的には、そのようなifステートメントのグループの前後に空白行を置いて、それらを他のコードから視覚的に分離します。すべてifが同じインデントで始まる一連のステートメントがあると、異常なことが明確に視覚的に示されます。