中括弧を省略するのはなぜ悪い習慣と考えられているのですか？[閉まっている]

なぜ誰もが私にこのようなコードを書くことは悪い習慣だと言っているのですか？

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

中括弧を省略することについての私の最大の議論は、中括弧が2倍になることがあるということです。たとえば、C＃でラベルのグロー効果をペイントするコードは次のとおりです。

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

また、usings何百万回もインデントする必要なしに、連鎖の追加の利点を得ることができます。

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

中括弧の最も一般的な議論は、保守プログラミングと、元のifステートメントとその意図した結果との間にコードを挿入することによって発生する問題を中心に展開します。

if (foo)
    Bar();
    Biz();

質問：

1. 言語が提供するよりコンパクトな構文を使用するのは間違っていますか？これらの言語を設計する人々は賢いです、彼らがいつも使うのが悪い機能を置くとは思えません。
2. 最も一般的な分母が理解し、問題なく動作できるようにコードを書くべきか、すべきでないか？
3. 私が見逃している別の議論はありますか？

実は、本当に私に噛まれたのは、デバッグしていて、bar（）をコメントアウトしたときだけでした。

if(foo)
  // bar();
doSomethingElse();

それ以外に、私は使用する傾向があります：

if(foo) bar();

上記のケースを処理します。

編集質問を明確にしてくれてありがとう、私は同意します、私たちは最低の共通項にコードを書くべきではありません。

読む速度...

すでに言及されているものは別として。この時点で、中括弧と空白を含むifステートメントを解析する条件がすでに整っています。だから私は読んだ：

if (condition)
{
    DoSomething();
}

DoSomethingElse();

私が読んだよりも少し速い：

if (condition) DoSomething();

DoSomethingElse();

次のようになっていると、少し遅く読みます。

if (condition) DoSomething();
DoSomethingElse();

私はこれを以前よりもかなり遅く読んだ：

if (condition) 
    DoSomething();
DoSomethingElse();

私は仕方がないので、念のためもう一度読んで、作者が意図したかどうか疑問に思います：

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

一般的にはすでにカバーされていますが、以下を読むことになると、著者が意図したことを確認するために、しばらくこれを調査します。確認のために元の作者を探し出すこともできます。

if (condition) 
    DoSomething();
    DoSomethingElse();

小さい場合は、次のように記述します。

if(foo()) bar();

2行に分割できるほど長い場合は、中括弧を使用します。

私はまた、本当に必要なときだけ中括弧を使う方が良いと思っていました。しかし、主な理由はもうありません。多くのコードがある場合、コードが読みやすくなり、一貫したブレーススタイルがある場合は、コードをより速く解析できます。

誰かがifに2番目のステートメントを追加する以外に、常に中括弧を使用するもう1つの理由は、次のようなことが起こります。

if(a)
   if(b)
     c();
else
   d();

else節が実際には「if（b）」の節であることにお気付きですか？あなたはおそらくそうしましたが、この落とし穴に精通している誰かを信頼しますか？

したがって、一貫性のためだけでなく、他の誰か（常に他の人が愚かである場合）がコードを変更したときに予期しない事態が発生する可能性があることがわからない場合は、常に中かっこを付けます。あなたの脳。委任が行われた、またはスイッチのようなifのように、句が拡張されないことがわかっている最も単純なifステートメントについてのみ、中括弧は省略します。

これは常に悪い習慣とは見なされていません。モノプロジェクトのコーディング・ガイドラインは、それが必要ではない場合、中括弧を使用しないように示唆しています。GNUコーディング標準についても同様です。コーディング標準ではいつものように個人的な好みの問題だと思います。

ラインは安いです。プロセッサ能力は安いです。開発者の時間は非常に高価です。

一般的なルールとして、絶対にリソース/速度が重要なアプリケーションを開発していない限り、常に次のようなコードを書くのは間違いです。

（a）他の開発者が私がやっていることを簡単に追跡できる

（b）コードを必要とする可能性のあるコードの特定の部分にコメントを付ける

（c）問題が発生した場合のデバッグが容易

（d）将来必要になった場合に簡単に変更できる（つまり、コードの追加/削除）

コードの速度や学術的な優雅さは、ビジネスの観点から見ると、これらの要素に次ぐものです。これは、私が不格好な、または醜いコードを書き始めようとしているわけではありませんが、これは私の優先順位です。

ほとんどの場合、中括弧を省略すると、（b）、（c）、（d）が難しくなります（ただし、不可能ではありません）。中括弧を使用してもしなくても、（a）には影響しません。

私は中括弧が提供する明快さを好みます。あなたは正確に何を意味しているのかを知っており、誰かが間抜けしてそれらを放置したかどうかを推測する必要はありません（そしてバグを導入しました）。省略しているのは、ifとactionを同じ行に記述したときだけです。私もそんなことはあまりしません。私は実際に中括弧を独自の行に置くことによって導入された空白を好みますが、K＆R Cのようなプログラミングの年月から、括弧で行を終了することは、IDEがそれを強制しない場合に克服しなければならない習慣です私。

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}

あなたが取り組んでいるプロジェクトのガイドラインと個人的な好みの問題だと思います。

次のような場合を除いて、必要がない場合は通常省略します。

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

私は好む

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

これがあなたに噛み付く可能性のあるインスタンスの1つは、昔のC / C ++マクロに戻っています。これはC＃の問題であることは知っていますが、多くの場合、コーディング標準は、標準が最初に作成された理由なしに引き継がれます。

マクロの作成時に細心の注意を払わないと、{}を使用しないifステートメントで問題が発生する可能性があります。

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

誤解しないでください。C/ C ++でこの問題を回避するためだけに常に{}を実行する必要があると言っているわけではありませんが、このために非常に奇妙なバグに対処する必要がありました。

私も同じように考えています。

1日まで（なぜあなたの人生を永遠に変えるその「1日」が常にあるのですか？）私たちは、睡眠なしで24〜36時間を費やして、検索/置換の変更と組み合わせて中かっこを付けていない人を見つけるためだけに本番コードをデバッグします。

こんな感じでした。

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

その後に来たのは

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

システムが毎日500 mbのログを生成していることがわかり、停止するように求められました。デバッグフラグが不十分だったため、printlnの検索と置換が必要でした。

それでもアプリが本番環境に移行したとき、デバッグフラグはオフで、重要な「saveDayData」は呼び出されませんでした。

編集

中かっこを使用しない唯一の場所は、if / tryコンストラクトです。

if( object != null ) try { 
     object.close();
} catch( .....

スーパースターの開発者がそれをしているのを見た後。

率直に言って、私はそれを次のように見ています：

優れたプログラマは防御的にプログラミングしますが、悪いプログラマはそうではありません。

上記の例がいくつかあり、中括弧を忘れることに関連するバグに関する私自身の同様の経験があるので、私は常に中括弧を置くための難しい方法を学びました。

安全性よりも個人的なスタイルを選択しているものは何でもあり、それは明らかに悪いプログラミングです。

ジョエルはこれを間違ったコードを間違って見えるようにすることで言及しています

中括弧がないためにバグに遭遇すると、別のバグが発生する可能性があることがわかっているため、中括弧がないと見た目が悪いことがわかります。

私はとても嬉しいです：

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

個人的には、理由はわかりません

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

これ以上読みやすいです。

はい、行は無料ですが、サイズが半分になる可能性があるのに、なぜページやコードのページをスクロールする必要があるのですか？

読みやすさや保守性に違いがある場合は、確かに中かっこを入れますが、この場合は理由がわかりません。

また、私は常にネストされたifに対して中括弧を置きます。

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

対

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

ひどく混乱しているので、私はいつも次のように書きます：

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

可能な場合は常に三項演算子を使用しますが、ネストすることはありません 。

「もしあなたが誰かにお金を払ってコードを書かせるほど賢いなら、コードの流れを見るのにインデントだけに頼らないように賢くすべきだ」と私は同意します。

ただし、...間違いを犯す可能性があり、これはデバッグするのが面倒です...特に他の誰かのコードを見ている場合は特にそうです。

私の哲学は、コードを読みやすくすることですが、なぜそれをしないのですか？

明らかに、どこかで線を引く必要があります。たとえば、簡潔な変数名と過度に記述的な変数名の中間にある幸せな媒体を見つけることです。しかし、ブラケットは本当にエラーを回避し、コードの可読性を向上させます。

プログラマーになるほど賢い人は、ブラケットのないステートメントに起因するバグを回避するのに十分賢くなると主張できます。しかし、正直言って、スペルミスのような単純なものにつまずかれたことは一度もないでしょうか。このようなマニューシャは、大規模なプロジェクトを見ると圧倒されます。

常に例外はありますが、次のいずれかの形式の場合に限り、中括弧を省略しないように主張します。

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

それ以外は問題ありません。

一番下のコード（複数のusingステートメント）を使用することもありますが、それ以外の場合は常に中かっこを使用します。コードがわかりやすくなるだけです。ステートメントがブロックの一部であること（したがって、おそらくifなどの一部であること）は、単なるインデント以上のものから明白に明らかです。

私は見ました

if (...)
    foo();
    bar();

バグが私（または「私と同僚」-実際にはバグを紹介しなかった）に一度かみついた。これは、当時の私たちのコーディング標準がどこでもブレースを使用することを推奨したという事実にもかかわらずでした。あなたが見たいものを見るので、それを見つけるのに驚くほど長い時間がかかりました。（これは約10年前のことです。たぶん、今はもっと早く見つけたでしょう。）

もちろん、「行末のブレース」を使用すると、余分な行が減りますが、個人的にはそのスタイルが嫌いです。（私は仕事でそれを使用しており、予想よりも不快ではないことがわかりましたが、それでも少し不快です。）

このコンピュータープログラミングの分野（あなたの多く）の仲間が、単一行ブロックで中かっこをスキップした場合の潜在的なバグの見通しに悩まされていないことに感銘を受け、謙虚に感じています。

それは私が賢くないことを意味すると思います。私はこれを何度も間違えました。私はこれについて他の人の間違いをデバッグしました。このため、ソフトウェアがバグとともに出荷されるのを見てきました（VS2002を実行しているマシンへのRDPとウォッチウィンドウフォントが不安定になります）。

コーディングスタイルを変更することで回避できた可能性のあるすべてのミスを見ると、リストは非常に長くなっています。これらの各ケースで自分のアプローチを変更していなければ、おそらくプログラマーとしてそれを実現することはなかっただろう。繰り返しますが、私は頭が悪いと思います。これを補うために、私は長い間、単線ブロックのブレースを頑固に使用してきました。

とはいえ、モーセが私たちに教えてくれたときよりも、「一行ブロックでは中括弧を使用する」というルールの重要性が低くなる、世界のいくつかの変化がありました。

• 一部の一般的な言語では、プログラマーが行うように（Pythonなど）、コンピューターにインデントを読み取らせることで問題を解決します。

• 私のエディターは自動的にフォーマットを設定するので、インデントによって誤解を招く可能性が大幅に減少します。

• TDDは、1行のブロックで混乱したためにバグを導入した場合、バグをすばやく発見する可能性がはるかに高くなることを意味します。

• リファクタリングと言語表現力は、私のブロックがはるかに短く、単一行のブロックが以前よりはるかに頻繁に発生することを意味します。仮に、ExtractMethodの冷酷なアプリケーションを使用すると、プログラム全体で単一行のブロックしか持てない可能性があります。（どうなるのだろう？）

実際、冷酷にリファクタリングし、単一行ブロックで中括弧を省略することには、明確な利点があります。中括弧が表示されると、頭の中で「複雑さここに注意！」という小さなアラームが鳴ることがあります。これが標準だったと想像してみてください：

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

コーディング規約を「単一行のブロックには中括弧を付けることはできない」または「条件と同じ行にブロックを置くことができ、すべてが80文字以内に収まる場合」のようなものに変更するという考えに私は心を開いています。ブレースを省略します。」わかります。

3つの規則のうち：

if(addCurleyBraces()) bugFreeSofware.hooray();

そして：

if(addCurleyBraces())
    bugFreeSofware.hooray();

と（開始と終了のブレースを使用したインデントスタイルを表します）：

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

私は最後のものを好む：

• すべてのifステートメントが統一された方法で記述されていると、読みやすくなります。
• これにより、ソフトウェアの堅牢性が高まり、バグがなくなります。ただし、すべての最新のIDEと高度なテキストエディターには素晴らしい自動インデント機能があり、コメントの書式をめちゃくちゃにしたり、チームの標準に違反したりしない限り、誰でも使用できると思います（多くの場合、カスタムの書式設定スキーマを作成できます）チームと共有します）。ここでの私のポイントは、インデントが正しく行われていれば、バグが導入されるリスクが少し軽減されるということです。
• 実行するブール式とステートメントを別の行に置くことを好みます。デバッグのために行をマークできるようにしたい。ステートメントをマークしてステップするIDEを使用している場合でも、それはインタラクティブな操作であり、デバッグを開始した場所を忘れるか、少なくともコードをいくつかステップ実行するのに少し時間がかかります回（デバッグ中に毎回手動で位置をマークする必要があるため）。

中括弧の使用に対する主な議論は、それらが追加の行を使用し、追加のインデントが必要であるということです。

行は（ほぼ）無料です。コードの行数を最小限に抑えることは目的ではありません。

また、インデントはブレースの使用とは無関係です。カスケードの「使用」の例では、中括弧を省略した場合でも、インデントする必要があると思います。

私は整頓された簡潔なコードを書くことを強く信じていますが、中括弧を常に使用します。特定のコード行が存在するスコープをすばやく確認するのに便利な方法であることがわかりました。曖昧さはありません、それはあなたの前に明示的に提示されているだけです。

好みのケースだと言う人もいるかもしれませんが、プログラムの論理フローが内部的に一貫していると、追跡がはるかに容易になると私は思います。

if(x < y)
    x = y;
else
    y = x;

そして、このような別のもの;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

私はただ一つの一般的なスタイルを選び、それに固執することを好みます:)

あなたはワンライナーと非一つの制御なステートメントからの分離に伴いライナー、（領域がある場合の主な問題の一つはfor、ifあなたが持っているもの）となステートメントの終わりを。

例えば：

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

私はかつて「中かっこは必須です！」の巨大な支持者でしたが、単体テストを採用して以来、私の単体テストは次のようなシナリオからブレースレスステートメントを保護することがわかりました。

if (foo)
    snafu();
    bar();

優れた単体テストを使用すると、読みやすさを向上させるために、単純なステートメントでは中かっこを自信を持って省略できます（そうです、これは主観的な場合があります）。

または、上記のようなものについては、おそらく次のようにインライン化します。

if (foo) snafu();

そうすれば、条件にbar（）を追加する必要がある開発者は、中括弧がないことを認識し、追加することができます。

個人的な判断を使用してください。

if (foo)
  bar();

それ自体は問題ありません。あなたが本当にこのようなものを後で入れている警戒心について本当に心配しているのでない限り：

if (foo)
  bar();
  baz();

moronsを心配していない場合は問題ありません（私はそうではありません-基本的なコード構文を正しく取得できない場合は、これが最小の問題です）>

引き換えに、それははるかに読みやすいです。

残りの時間：

if (foo) {
  bar();
  baz();
}

私が覚えている限り、これは私のお気に入りです。さらに：

if (foo) {
  bar();
  baz();
} else {
  qux();
}

私のために働く。

垂直方向のスペース自体はそれほど重要ではなく、読みやすさは重要です。行の開始ブレースは、目が次の行に移動するまで、構文要素の会話を停止します。私が好きなものではありません。

さて、これは死に答えられた古い質問です。追加するものがあります。

最初に私はただブレースを使用しなければならない。それらは読みやすさを助けるだけであり、アセンブリを書いているのでない限り、（自分自身と他の人にとって）読みやすさは優先リストで非常に高くなければなりません。常に読み取り不可能なコードは、常にバグを引き起こします。中かっこによってコードが占める領域が多すぎる場合は、メソッドが長すぎる可能性があります。正しく実行している場合、メソッドのほとんどまたはすべてが1つの画面の高さに収まるはずであり、検索（F3）がお友達です。

今私の追加のために：これに問題があります：

if (foo) bar();

bar（）が実行される場合にのみヒットするブレークポイントを設定してみてください。コードの後半にカーソルを置くことでC＃でこれを行うことができますが、これは明白ではなく、少し面倒です。C ++では、それはまったくできませんでした。この理由により、C ++コードに取り組んでいる最上級の開発者の1人は、「if」ステートメントを2行に分割することを強く求めています。そして私は彼に同意します。

これを行います：

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}

中かっこ付きのコードが多くのスペースを占有しないようにするために、「Code Complete」という本で推奨されている手法を使用します。

if (...) {
    foo();
    bar();
}
else {
    ...
}

いくつかのコードがあるとしましょう：

if (foo)
    bar();

そして、他の誰かがやって来て追加します：

if (foo)
    snafu();
    bar();

それが書かれている方法によると、bar（）; 無条件に実行されるようになりました。中括弧を含めることで、この種の偶発的なエラーを防止できます。コードは、そのような間違いを困難または不可能にするような方法で書かれるべきです。コードレビューを行っているときに、特に複数の行にまたがって中かっこが見つからない場合は、欠陥を作成します。正当化される場合は、このようなエラーが発生する可能性が再び最小限に抑えられるように、1行に収めてください。

線を減らすことは、中括弧を削除するための本当に良い議論ではありません。メソッドが大きすぎる場合は、小さな要素にリファクタリングするか、再構築する必要があります。そうすることで、中括弧を外すだけで読みやすさが向上することは間違いありません。

最初の例のように、適切な場合は常に省略します。一目で確認して理解できる簡潔で簡潔なコードは、1行ずつスクロールして読み取る必要があるコードよりも、保守、デバッグ、および理解が容易です。ほとんどのプログラマーはこれに同意するでしょう。

複数の入れ子やif / else句などを使い始めると手に負えなくなるのは簡単ですが、ほとんどのプログラマはどこに線を引くかを指示できるはずです。

それはif ( foo == 0 )vs の議論のようなものだと思いますif ( 0 == foo )。後者は、新しいプログラマー（場合によっては退役軍人の場合もある）のバグを防ぐ可能性がありますが、前者の方がコードを保守しているときにすばやく読み、理解するのが簡単です。

ほとんどの場合、企業またはFOSSプロジェクトのどちらであっても、コーディング標準として組み込まれています。

最終的には、他の誰かがあなたのコードを理解する必要があり、各開発者が作業しているコードのセクションの特定のスタイルを理解しなければならないことは、大きな時間の浪費です。

また、誰かが1日に複数回PythonとCish言語の間を行き来していると想像してみてください... Pythonでは、インデントは言語のブロック構文の一部であり、引用するような間違いを犯しがちです。

より安全な面でエラーが発生しました-修正する必要のない可能性のあるバグがもう1つあります。

私のすべてのブロックが巻き毛で包まれていれば、個人的にはより安全だと感じます。ワンライナーの場合でも、これらは簡単に間違いを防ぐための単純な表記法です。これにより、ブロックの本体がブロックの外側にある次のステートメントと混同されないように、ブロックの内容を明確に理解できるという意味で、コードが読みやすくなります。

ワンライナーがある場合、通常は次のようにフォーマットします。

if( some_condition ) { do_some_operation; }

行があまりにも扱いにくい場合は、以下を使用します。

if( some_condition )
{
    do_some_operation;
}