中括弧を省略するのはなぜ悪い習慣と見なされるのですか？
なぜ誰もがこのようなコードを書くのは悪い習慣だと私に言うのですか？
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));
また、100万回インデントすることなく、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();
質問：
- 言語が提供するよりコンパクトな構文を使用したいのは間違っていますか？これらの言語を設計する人々は賢く、私は彼らがいつも使うのが悪い機能を置くと想像することはできません。
- 最も一般的な分母が理解し、問題なく作業できるように、コードを書くべきですか、すべきではありませんか？
- 私が見逃している別の議論はありますか？
実際、私がデバッグしているときだけが本当に私を苦しめたのは、bar（）をコメントアウトしたときだけでした。
if(foo)
// bar();
doSomethingElse();
それ以外に、私は使用する傾向があります：
if(foo) bar();
上記のケースを処理します。
[〜＃〜] edit [〜＃〜]質問を明確にしてくれてありがとう、同意します。最低公分母にコードを書くべきではありません。
読み取り速度...
既に言及されていることは別として。この時点で、中括弧と空白を含むifステートメントを解析するように既に条件付けられています。だから私は読んだ：
if (condition)
{
DoSomething();
}
DoSomethingElse();
私が読むより少し速い：
if (condition) DoSomething();
DoSomethingElse();
このように見える場合、少し遅く読みます。
if (condition) DoSomething();
DoSomethingElse();
私はこれを以前よりもかなり遅く読んだ：
if (condition)
DoSomething();
DoSomethingElse();
私は助けてあげることができないので、念のためにもう一度読んで、著者が意図したのかどうか疑問に思います：
if (condition)
{
DoSomething();
DoSomethingElse();
}
すでに一般的に説明されていますが、reading以下に関しては、著者が何を意図しているかを確認するために、これをかなり長い間調べていきます。確認するために元の作者を追い詰めることさえできます。
if (condition)
DoSomething();
DoSomethingElse();
小さい場合は、次のように記述します。
if(foo()) bar();2行に分割するのに十分な長さがある場合は、中括弧を使用します。
また、本当に必要なときだけブレースを使用する方が良いと思っていました。しかし、主な理由は、多くのコードがある場合、コードを読みやすくし、一貫したブレーススタイルがある場合にコードをより速く解析できることです。
Ifに2番目のステートメントを追加する以外に、常に中括弧を使用するもう1つの理由は、次のようなことが起こる可能性があることです。
if(a)
if(b)
c();
else
d();
Else節は実際には「if（b）」の節であることに気づきましたか？あなたはおそらくそうしましたが、誰かがこの落とし穴に精通していると信頼しますか？
したがって、一貫性のためだけに他の誰か（常に他の人が愚かである）がコードを変更したときに予期しないことが起こる可能性がまったくわからない場合、私は常に中括弧を付けます。より読みやすく、脳でより速く解析できます。最も単純なifステートメント（委任が行われた場合やスイッチのようなifの場合、節が延長されないことがわかっている場合）についてのみ、中かっこは省略します。
ラインは安いです。プロセッサの電力は安価です。開発者の時間は非常に高価です。
一般的なルールとして、絶対にリソース/速度が重要なアプリケーションを開発していない限り、コードを書く側では常にエラーが発生します。
（a）他の開発者が私がやっていることを簡単にフォローできる
（b）コードの特定の部分をコメントする
（c）何かがうまくいかない場合でも簡単にデバッグできる
（d）将来必要になる場合は簡単に変更できます（コードの追加/削除）
コードの速度またはアカデミックな優雅さは、ビジネスの観点からこれらの要因に次ぐものです。これは、私が不格好なまたはcodeいコードを書くことに着手したと言うことではありませんが、これは私の優先順位です。
ほとんどの場合、中括弧を省略すると、（b）、（c）、および（d）がより難しくなります（ただし、不可能ではないことに注意してください）。中括弧を使用してもしなくても、（a）には影響しません。
中括弧が提供する明快さを好みます。意味を正確に理解しているので、誰かがだまされてそれらを中断したかどうかを推測する必要はありません（バグが発生しました）。それらを省略したのは、ifとアクションを同じ行に置いたときだけです。私もそんなことはあまりしません。私は実際には、中括弧を独自の行に置くことによって導入された空白を好みますが、長年のK＆R Cのようなプログラミングから、行を中括弧で終了することは、IDEは私にそれを強制しません。
if (condition) action(); // ok by me
if (condition) // normal/standard for me
{
action();
}
これは常に悪い習慣とは見なされません。 Mono Project Coding Guidelines は、必要でない場合は中括弧を使用しないことを示唆しています。 GNU Coding Standards についても同じです。私はそれがいつもコーディング標準と同様に個人的な好みの問題だと思います。
それはあなたが取り組んでいるプロジェクトのガイドラインと個人的な好みの問題だと思います。
次のような場合を除いて、通常は不要な場合は省略します。
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
}
私は同じように考えるために使用します。
ある日まで（なぜあなたの人生を永遠に変える「その日」が常にあるのでしょうか？）私たちは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」は呼び出されませんでした。
[〜＃〜] edit [〜＃〜]
今、私が中括弧を使用しない唯一の場所は、if/try構文です。
if( object != null ) try {
object.close();
} catch( .....
スーパースター開発者がそれをしているのを見た後。
これが噛みつく可能性のあるインスタンスの1つは、昔のC/C++マクロに戻っています。これはC＃の質問であることは知っていますが、多くの場合、コーディング標準は最初に作成された理由がなくても引き継がれます。
マクロを作成するときにあまり注意しないと、{}を使用しないifステートメントで問題が発生する可能性があります。
#define BADLY_MADE_MACRO(x) function1(x); function2(x);
if (myCondition) BADLY_MADE_MACRO(myValue)
誤解しないでください。C/ C++でこの問題を回避するために常に{}を実行する必要があると言っているわけではありませんが、このため非常に奇妙なバグに対処する必要があります。
私は非常に満足しています：
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;
より読みやすいです。
はい、行は無料ですが、サイズが半分になる可能性があるのに、ページやコードのページをスクロールする必要があるのはなぜですか？
読みやすさや保守性に違いがある場合は、中括弧を入れてください...しかし、この場合、理由はわかりません。
また、私はalwaysネストされた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();
}
可能な限り、三項演算子を使用しますが、Inevernest them です。
率直に言って、私はそれを次のように見ています：
優秀なプログラマーは防御的にプログラムしますが、悪いプログラマーは防御しません。
上記のいくつかの例と、ブレースを忘れることに関連するバグの私自身の同様の経験があるので、常にブレースを置くハードな方法を学びました。
他のことは安全よりも個人的なスタイルを選択することであり、それは明らかに悪いプログラミングです。
ジョエルは コードの見た目が間違っている
中かっこがないためにバグに少し慣れると、別のバグが発生する可能性がある場所であることがわかっているため、中かっこが間違っているように見えることがわかります。
このコンピュータープログラミングの分野の仲間（皆さん）は、単一行のブロックのブレースをスキップしたときに潜在的なバグの可能性に気を取られないことに感銘を受け、謙虚になりました。
それは私が頭が良くないことを意味すると思います。私はこれについて何度もミスをしました。私はこれについて他人の間違いをデバッグしました。このため、ソフトウェアの出荷にバグがあります（VS2002を実行しているマシンへのRDPと、ウォッチウィンドウのフォントが不安定になります）。
コーディングスタイルを変更することで回避できたすべてのミスを見ると、リストは非常に長くなっています。これらの各ケースでアプローチを変更していなければ、おそらくプログラマーになることはなかったでしょう。繰り返しになりますが、私は頭が良くないようです。これを補うために、私は長い間、単一行ブロックのブレースの堅実なユーザーでした。
とはいえ、モーゼスが私たちにそれをもたらしたときよりも、「あなたは単一行ブロックにブレースを使用する」ルールの関連性を低くするいくつかの事柄が世界で変わった：
いくつかの一般的な言語では、プログラマーと同じように、コンピューターにインデントを読み取らせることで問題を解決します（Pythonなど）。
私のエディター自動フォーマット私にとっては、インデントによって誤解を招く可能性が大幅に減少します。
[〜＃〜] tdd [〜＃〜]は、1行のブロックで混乱するためにバグを導入すると、すぐにバグを発見する可能性が高くなることを意味します。
リファクタリングと言語表現力は、私のブロックがはるかに短く、単一行のブロックが以前よりもはるかに頻繁に発生することを意味します。仮説的に、ExtractMethodの無慈悲なアプリケーションでは、プログラム全体にonlyの単一行ブロックを含めることができます。 （どのように見えるのだろうか？）
実際、容赦なくリファクタリングを行い、単一行ブロックのブレースを省略することには明確な利点があります。ブレースが表示されると、「ここで複雑さ！気をつけてください！」という小さなアラームが頭に鳴ります。これが標準であったと想像してください：
if (condition) Foo(); // normal, everyday code
if (condition)
{
// something non-trivial hapening; pay attention!
Foo();
Bar();
}
私は、コーディング規則を「単一行のブロックに括弧がない」または「条件と同じ行にブロックを置くことができ、すべてが80文字以内に収まる場合」のようなものに変更するというアイデアに心を開いています。中括弧を省略します」。表示します。
例外は常にありますが、ブレースが次の形式のいずれかである場合にのみ、ブレースを省略することに反対します。
if(x == y) for(/* loop */) { //200 lines } //rampion's example: for(/* loop */) { for(/* loop */) for(/* loop */) { //several lines } }
そうでなければ、私はそれで問題はありません。
ときどき一番下のコード（複数のusingステートメント）を使用しますが、それ以外は常に中かっこを挿入します。コードがわかりやすくなるだけです。インデントだけでなく、文がブロックの一部である（したがって、おそらくifなどの一部である）ことは明白です。
私は見ました
if (...)
foo();
bar();
バグが私をかみます（むしろ「私と同僚」-私は実際にバグを紹介しませんでした）once。これは、当時のコーディング標準がどこでもブレースを使用することを推奨していたという事実にもかかわらずでした。あなたが見たいものを見ているので、見つけるのに驚くほど長い時間がかかりました。 （これは約10年前でした。たぶん今はもっと早く見つかると思います。）
もちろん、「行末にブレース」を使用すると、発生する余分な行が減りますが、とにかくそのスタイルは嫌いです。 （私は職場でそれを使用しており、予想よりも不快ではないことがわかりましたが、それでも少し不快です。）
「誰かにコードを書いてもらうためにお金を払うほど賢いなら、コードの流れを見るためにインデントだけに頼らないほど賢くなければならない」と私は同意します。
しかし...間違いが発生する可能性があり、これはデバッグするのが面倒です...特に他の人のコードを見ている場合はそうです。
私の哲学は、それがコードをより読みやすくするなら、なぜそれをしないのですか？
明らかに、簡潔で過度に説明的な変数名の間の幸福な媒体を見つけるように、どこかに線を引く必要があります。しかし、括弧は本当にエラーを回避し、コードの可読性を改善します。
コーダーになるほど頭がいい人は、括弧のないステートメントを引き起こすバグを回避するのに十分頭がいいと主張することができます。しかし、スペルミスのような単純なものにつまずいたことは一度もないと正直に言うことができますか？このような細目は、大規模なプロジェクトを見ると圧倒されます。
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++;
}
私はただ一つの一般的なスタイルを選んでそれを使い続けることを好みます:)
中括弧の使用に対するあなたの主な議論は、追加の行を使用し、追加のインデントを必要とすることです。
行は（ほとんど）自由であり、コード内の行数を最小限にすることは目的ではありません。
また、インデントはブレースの使用とは無関係です。カスケードの「使用」の例では、中括弧を省略してもインデントする必要があると考えています。
さて、これは死に答えられた古い質問です。追加することがあります。
最初に私はただ、ブレースを使うと言わなければなりません。それらは読みやすさを助けるだけであり、アセンブリを書いているのでなければ、自分自身や他の人にとっての読みやすさは優先リストで非常に高くすべきです。読み取り不能なコードは常に、常にバグにつながります。中括弧がコードのスペースを取りすぎることがわかった場合、メソッドはおそらく長すぎます。正しい方法であれば、メソッドのほとんどまたはすべてが1つの画面の高さに収まる必要があり、Find（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.
}
主な問題の1つは、コントロールステートメント（for、if、何がありますか）からの分離とともに、1ライナーと非1ライナーの領域がある場合です。声明。
例えば：
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();
あなたがバカを心配していないなら、あなたは大丈夫です（私はそうではありません-彼らが基本的なコード構文を正しく得ることができなければ、これは彼らの問題の最小です）>
代わりに、はるかに読みやすくなっています。
残りの時間：
if (foo) {
bar();
baz();
}
私が覚えている限り、これは私のお気に入りでした。さらに：
if (foo) {
bar();
baz();
} else {
qux();
}
私のために働く。
縦方向のスペース自体はそれほど重要ではなく、読みやすさは重要です。線の開始ブレース自体は、目が次の行に移動するまで、構文要素の会話を停止します。私が好きなものではありません。
いくつかのコードがあるとしましょう：
if (foo)
bar();
そして、他の誰かが来て追加します：
if (foo)
snafu();
bar();
書かれた方法によると、bar（）;今では無条件に実行されます。中括弧を含めることにより、この種の偶発的なエラーを防ぎます。コードは、そのようなミスを困難または不可能にするような方法で作成する必要があります。コードレビューを行っていて、特に複数行に広がるブレースの欠落を見た場合、欠陥が作成されます。正当な理由がある場合は、このようなエラーが発生する可能性が再び最小限に抑えられるように、1行にしてください。
行を減らすことは、中括弧を削除するための実際の良い議論ではありません。メソッドが大きすぎる場合は、おそらく小さな要素にリファクタリングするか、再構築する必要があります。それを行うことは、単に中括弧を取り出すことよりも間違いなく読みやすさを高めるでしょう。
中括弧付きのコードが多くのスペースを占有しないようにするために、本で推奨されている手法を使用します Code Complete ：
if (...) {
foo();
bar();
}
else {
...
}
最初の例のように、適切な場合は常に省略します。一見するだけでわかりやすく簡潔に理解できるコードは、1行ずつスクロールして読み取るコードよりも、保守、デバッグ、理解が容易です。ほとんどのプログラマーはこれに同意すると思います。
複数のネスト、if/else句などを行うと簡単に手に負えなくなりますが、ほとんどのプログラマーはどこに線を引くかを伝えることができると思います。
if ( foo == 0 ) vs if ( 0 == foo )の引数のように見えます。後者は、新しいプログラマのバグを防ぐ可能性があります（ベテランの場合もあります）が、前者はコードを保守しているときにすばやく読み、理解するのが簡単です。
ほとんどの場合、企業向けであれFOSSプロジェクト向けであれ、コーディング標準として定着しています。
最終的には他の誰かがコードを理解する必要があり、各開発者が作業しているコードのセクションの特定のスタイルを把握する必要があるため、大きな時間の浪費になります。
また、誰かがPythonとCish言語を1日に1回以上行き来していると想像してみてください... In Pythonインデントは、あなたが引用したような間違いを犯すことは非常に簡単です。
より安全な側のエラー-修正する必要がない可能性があるもう1つのバグ。
すべてのブロックがカーリーで包まれている場合、私は個人的に安全だと感じています。ワンライナーの場合でも、これらは単純な表記法であり、間違いを簡単に防ぐことができます。ブロックの内容をブロック外の次のステートメントと混同しないように、ブロック内の内容を明確に見るという意味で、コードが読みやすくなります。
ワンライナーがある場合、通常は次のようにフォーマットします。
if( some_condition ) { do_some_operation; }
行が面倒な場合は、次を使用します。
if( some_condition )
{
do_some_operation;
}
両方の長所を組み合わせた代替方法は次のとおりです。
if(foo)
{DoSomething();}
これにより、行がコメント化されているか、その下に別の行が追加されている場合の混乱を回避できます。
また、コーディング標準として MISRA-C を使用します。これは、すべての状況で中括弧を使用するためにこのようなすべての構成体を必要とします。
彼らはまだ古代または汎用の（言語を認識しない）ソースコードエディターを使用しているため、彼らはあなたに言います。自動インデントを備えたエディターを使用する場合、常に中括弧を使用することで回避できた間違いを犯すことはありません。
- 空白は無料です。
- 将来の可読性のためにインデントに依存することは、タブ設定に依存することを意味しますが、これは良い考えではありません。リビジョン管理下にない10年前のコードに取り組んだことがありますか？
- 私の経験では、中括弧を入力しないことで節約した時間は、意味を理解するのに余分な時間を費やすことで失われます。
ポールは言った：
また、インデントはブレースの使用とは無関係です。
一部のコーディングスタイルではそうではありません。私が働いている場所では、会社のコーディング標準により、厳密に必要でない場合は中括弧なしで行うことができます。ただし、コーディング標準により、中括弧とその中身がインデントされるため、次のような結果になります。
if (something)
{
for (i = 0; i < count; i++)
{
foo();
}
}
中括弧なしでは、これは次のようになります。
if (something
for (i = 0; i < count; i++)
foo();
このコーディングスタイルでは、長い変数名と関数名とともに深い入れ子があり、常に中かっこを使用すると、画面の右側から大量のコードが表示されるか、多くの行の折り返しが発生します。 、コードの読み取りやデバッグが面倒になります。この理由で、私はそうすることで逃げることができるときはいつでも常に中括弧を省く傾向があります。
Ifと同じ行に単一のステートメントを置くことに関しては、一部の企業のコーディング標準（私たちを含む）はそれを禁止しているため、常にオプションとは限りません。
私の選択なら、中括弧のレベルをif、forなどに変更し、本文の最初の行（またはコメント）を開き中かっこと同じ行にするように、会社のコーディング標準を変更します。
if (something)
{ for (i = 0; i < count; i++)
{ foo();
}
}
その場合、ブレースの各ペアは追加の行を1行だけ追加し、noを追加するため、常にブレースを使用する（および「ブレースを常に使用する」ルールをサポートするようになる）インデント。ブレースをまったく持たないのと同じくらいコンパクトにします。
あなたの保守プログラマーは、アプリにロジックを追加する場合、後で中括弧を追加するのを忘れることがあります。したがって、次のことが起こります。
if(foo)
bar();
bar(delete);
の代わりに
if(foo) {
bar();
}
bar(delete);
if ( any ) {
DoSomething();
}
- これが大きすぎると思われる場合は、1行で記述できます。
if ( any ) { DoSomething(); }あなたが考えると、1行で読みにくいので、2行で書くことができます：
if ( any ) { DoSomething(); } if ( any ) { DoSomething(); }- 将来、誰かが1つのステートメントを複数のステートメントに変更する必要があります。括弧がないと、変更はより複雑になります。はい、ほんの少しですが、バグを防ぐ方が良いです。そして、括弧を書くことは非常に簡単で安価な方法です。
中かっこを省略することは常に悪い習慣だとは思いませんが、許可されるべきかどうか、どのような状況でチームで合意する必要があるかを考えます。
これは非常に読みやすいと思います：-
if (foo)
bar();
この：-
if (foo)
bar()
else
snafu();
これらに余分な行が追加された場合：-
if (foo)
bar();
snafu();
これはすべて間違っているように見えます。インデントされたコードブロックがあります。しかし、ブレースはありません。
同様の引数がforループにも当てはまります。しかし、ネストを開始すると：-
if (foo)
if (bar)
snafu()
今、私は問題に直面しています、それはステートメントのブロックのように見えます。個人的には、外側のコードにブレースを使用させるほど、1レベルだけブレースの使用をスキップします。
if (foo) {
if (bar)
snafu()
}
これを入力していると、答えが1から17にジャンプするのがわかりました。これは明らかに感情的な質問になります（タグリストに主観を追加することをお勧めします（これを行う私の能力は、それについて何が欠けているのですか？ ））。
最も重要なことは、チーム内で受け入れられるかどうか、どのように受け入れられるかについて合意することです。
私は自分自身を中かっこが嫌いでした。ある日まで、私はそれらの使用法を見つけました。私は、プラットフォーム間でアプリケーションを移植するさまざまなプラットフォームで作業しています（合計6つの作業）。 UNIXでは、vimがインストールされている場合、「Shift + 5」を押すと、コードブロックの末尾または先頭に簡単にジャンプできます。これらは主にif/elseブロックまたはループです。
そのため、vimでRampionの問題を見ると、完全に失われ、コードを完全に理解するのに時間がかかります。
私はそれがすべて好みと読みやすさに要約されると思います。通常、中括弧を追加すると、コードと実際の行の間に余分なスペースがあるため、コードがはるかに読みやすくなります。また、この例を考慮してください（意図的にインデントされていません）：
if (condition1)
if (condition2)
doSomething();
else
doSomethingElse();
DoSomethingElseはいつ呼び出されますか？ condition1がtrueでcondition2がfalseの場合、またはcondition1がfalseの場合中括弧を追加すると、この読みやすさの問題がすぐに解決され、混乱が避けられます。
「このスタイルはスペースを節約します」を見ると、いつも困惑します。
コードを印刷することはめったにないので、スペースの増加は私にとって明らかな利点がありません。ディスクにいくつかのバイトを保存してもそれだけの価値はありません。
コンパクトコードの方が読みやすいと思う人もいますが、私はこれを主張しません（非常に主観的）。
上記の引数は繰り返しませんが、一貫性を追加します。次のようなコードは嫌いです
if (foo)
{
// Lot of code
}
else
DoStuff();
そうは言っても、私はいつか中かっこに夢中になります。
if (somethingBadHappened)
return;
要約すると、重要なコードの周りに（ほぼ）体系的に中括弧を追加すると、読みやすさ（コード「呼吸」、cr屈にならない）、一貫性が向上し、いくつかの愚かな間違い（はい、この種のエラーは明らかですが、コーダーは人間です） （一般的に）、疲れて、初心者、ストレス下にあります...）。
SciTE用のLuaマクロを作成して、コードブロックまたは現在の行にこれらのブレースを1回のキーストロークと正しいインデントで追加しました。費用はかかりません。
これらの括弧を省略することを選択した場合、私はあなたを訴えません。他の人が指摘しているように、コーディングルールでいずれかのオプションを設定できます。それぞれに。
これはトレードオフであり、短いコード（読みやすい）と安全性の高いコード（エラーが少ない）です。
私の2セント：
- このルールには理由があります。これは、無数のプログラマーが夜間や翌朝まで伸びて、少しの見落としによって引き起こされたバグを修正しようとして、無数のプログラマーによって開発されました。
- トレードオフに価値があるかどうかを自分で決めることはできません。
- 私の経験では、私は厄介なバグの原因を見つけるために夜に働いていた無数のプログラマーの一人です。原因は私が怠けていたことです。
私はよりコンパクトなフォーマットも気に入っています。これが、Visual Studioで再フォーマットするためにCtrl + K、Ctrl + Dを常に押す理由です。キーを押すたびにこれを実行できるようにしたいのです。
一方では、単一のステートメントについては中括弧を省略します。一方、私はすべてのCコードをPC-Lint（ http://www.gimpel.com/ ）でチェックします。これは、if（）ステートメントに続く2行以上のインデントされた行を「疑わしい」インデント」。
ちなみに、if（）と同じ行に単一のステートメントを置くのは良い考えのようです。
StyleCopがそう言っているからです。
「時々」感じる場合は、ブレースを使用すると便利です。一貫性を保つために、ブレースを追加する必要があります。プログラムは、コンピューターではなく人が読むように作成する必要があります。私は次のような中括弧を好む：
if (mybool)
{
doMyStuff();
}
else
{
doMyOtherStuff();
checkStuff();
}
好きじゃない
if (mybool) {
doMyStuff();
}
else {
doMyOtherStuff();
checkStuff();
}
好きじゃない
if (mybool)
doMyStuff();
else
{
doMyOtherStuff();
checkStuff();
}
私は、最も内側のステートメントがシングルライナーであると仮定して、最も内側のステートメントを除いて、常に中括弧を使用します。だから私のコードは次のようになります：
for (int i=0; i<10; i++)
{
for (int x=0; x<20; x++)
{
if (someBoolValue)
DoThis(x,y);
}
}
もちろん、他の例外はステートメントを使用してスタックされます。
書く意味は全くありません
using (Stream x = File.Open(...))
{
using (Stream y = File.Create(...))
{
...
}
}
あなたが書くことができるとき
using (Stream x = File.Open(...))
using (Stream y = File.Create(...))
{
....
}
他の考えでは、行を保存するために中括弧を削除する/使用しない場合、コードをリファクタリングする必要があります。
わかりました、これは私にとってより個人的な好みのように常に私に思えました。ただし、読みやすさのために、{}を使用してから使用しない方がよいことに気付きました。 ReSharperを使用すると、ReSharperがそれらを削除する傾向があることに気付きました。
if(this == yes)
DoSomething();
しかし、読みやすさのために私はいつも
if(this == yes)
{
DoSomething();
}
「if」ステートメントのコードは1行だけで読みやすさはそれほど変わりませんが、1つのifステートメントに20〜30行のコードを入れると、{}で読みやすくなり、エラーの余地が少なくなります。コードのバグ。