これは聖戦ではなく、「どちらが優れている」という問題でもありません。
単一ステートメントの if ブロックに次の形式を使用する利点は何ですか。
if (x) print "x is true";
if(x)
print "x is true";
とは対照的に
if (x) { print "x is true"; }
if(x) {
print "x is true";
}
単一ステートメントの if 文を角かっこなしでフォーマットする場合、またはそうするプログラマーを知っている場合、最初にこのスタイルを採用した理由は何ですか? これがあなたにどのような利益をもたらしたかに特に興味があります。
更新：最も一般的な回答は実際の質問を無視しているため（たとえそれが最も正気なアドバイスを提示していたとしても）、ここに括弧のない長所のまとめがあります.
私はこれを見つけます：
if( true ) {
DoSomething();
} else {
DoSomethingElse();
}
これより良い：
if( true )
DoSomething();
else
DoSomethingElse();
こうすれば、私 (または他の誰か) が後でこのコードに戻ってブランチの 1 つにさらにコードを追加する場合、コードを中かっこで囲むのを忘れる心配がありません。私たちの目は、行おうとしていることの手がかりとしてインデントを視覚的に認識しますが、ほとんどの言語はそうではありません。
if のテストと本文を同じ行に配置するスタイルは、私は強く嫌います。
これは、行を共有すると、多くのデバッガーで if の本体にブレークポイントを設定できなくなるためです。ブレークポイントは通常、行番号ベースであるためです。
常に中かっこを使用することは良い考えですが、「誰かがコード行を追加して中かっこを追加するのを忘れたらどうなるでしょうか?」という標準的な答えが常に与えられます。はかなり弱い理由です。
最初からブレースがないことによって導入される可能性のある微妙なバグがあります。それは私に数回起こり、他のプログラマーにも起こるのを見てきました。
それは単純な if ステートメントから始まります。
if (condition)
do_something();
else
do_something_else();
これはすべて順調です。
その後、誰かがやって来て、if に別の条件を追加します。ロジックが正しくないため、&& を使用して if ステートメント自体に追加することはできません。そのため、別の if を追加します。私たちは今持っています：
if (condition)
if (condition2)
do_something();
else
do_something_else();
問題が見えますか？正しく見えるかもしれませんが、コンパイラはそれを別の方法で認識します。次のように表示されます。
if (condition)
if (condition2)
do_something();
else
do_something_else();
つまり、まったく違うものを意味します。コンパイラはフォーマットを気にしません。else は最も近い if と一緒です。一方、人間はフォーマットに依存しているため、問題を見逃す可能性があります。
いつも使っています
if(x)
{
print "x is true";
}
中括弧を省略すると、現在の行の後に行を追加すると、コードを保守している人が if 句に追加していると誤解する可能性があります。
私が使う
if（x）
{{
DoSomething（）;
}
複数の行の場合ですが、ブラケットのない1つのライナーが好きです。
if（x） DoSomething（）; そうしないと DoSomethingElse（）;
無関係な角かっこは視覚的に不快であり、別のステートメントを追加するときに角かっこを追加しないという上記の間違いの1つを犯したことはありません。
if
{
// code
}
else
{
// else code
}
コードのブロックが（中かっこを含めて）並んでいるのが好きだからです。
Matt (上記 3) のように、私は次のことを好みます。
if (x)
{
...statement1
...statement2
}
と
if (x)
...statement
else
...statement
誰かが後でやって来て、複数行の if ブロックを形成するためにブレースを追加する必要があることに気付かないのはかなり奇妙だと思います。それが彼らの能力を超えている場合、他に何があるのだろうか！
私がコーディングした場合：
if(x)
print "x is true";
6 か月後に新しい行を追加する必要がある場合、中かっこがあると入力する可能性がはるかに低くなります
if(x)
print "x is true";
print "x is still true";
これは論理エラーになりますが、次のようになります。
if(x) {
print "x is true";
print "x is still true";
}
したがって、中括弧を使用すると、そのような論理エラーが読みやすくなり、回避しやすくなります。
関数の先頭でブレーク条件をテストするときは、1 行だけにする傾向があります。これは、このコードをできるだけシンプルで整頓したいからです。
public void MyFunction(object param)
{
if (param == null) return;
...
}
また、中かっこを避けて if 節のコードをインライン化したい場合は、それらを 1 行にまとめることができます。そのため、if に新しい行を追加する人にとっては、その大かっこを追加する必要があることは明らかです。
単一ステートメントの if ブロックに中かっこがない:
長所：
短所：
次のように:
if(x)
print "x is true";
print "something else";
Joel Spolskyが良い記事を書きました：間違ったコードを間違って見えるようにする
彼は特にこの問題に取り組んでいます…
if (i != 0) foo(i);この場合、コードは100％正しいです。これはほとんどのコーディング規約に準拠しており、問題はありませんが、ifステートメントの単一ステートメントの本体が中括弧で囲まれていないという事実は、頭の後ろで考えている可能性があるため、あなたを悩ませている可能性があります。そこに別のコード行を挿入する可能性があります
if (i != 0) bar(i); foo(i);…そして中かっこを追加するのを忘れて、誤ってfoo（i）を無条件にします！したがって、中かっこで囲まれていないコードのブロックを見ると、不快感を与える汚れのほんの小さな、ちっぽけなスープを感じるかもしれません。
彼はあなたに…
…コードを意図的に設計して、汚れが気になるとコードが正しくなる可能性が高くなるようにします。
必要でないときにブレースを使用するのは嫌いです。メソッドの行数が膨れ上がり、読めなくなっているような気がします。そのため、私はほとんどの場合、次のことを行います。
if (x)
print "x is true"
for (int i=0; i<10; i++)
print "y is true"
などなど。別のステートメントを追加する必要がある場合は、ブレースを追加するだけです。R# やそれに類するものを持っていなくても、それは非常に小さな取引です。
それでも、ステートメントに 1 行しかない場合でも中括弧を使用する場合があります。それは、その行が特に長い場合、またはその「if」内にコメントが必要な場合です。基本的には、自分の目に良いと思うものを使っています。
私が使う
if (cond) {
...
} else {
...
}
ホワイトスペースはあなたの友達です....
しかし、繰り返しますが、私は好きです：
if (foo)
{
Console.WriteLine("Foobar");
}
まじめな話、どこかのコードにバグがあったのはいつですか。
if (a)
foo();
bar();
ええ、決して...* ここでの唯一の真の「プロ」は、周囲のコードのスタイルに合わせて、大学を卒業したばかりの子供たちに美的戦いを任せることです。
*(警告は foo(); bar(); がマクロ展開であった場合ですが、これはマクロの問題であり、ifs を使用した中括弧ではありません。)
if (x) {
print "x is true";
}
else {
do something else;
}
私はいつも中かっこを入力します。それはちょうど良い習慣です。考えることに比べれば、タイピングは「仕事」ではありません。
条件の前のスペースに注意してください。これにより、メソッド呼び出しのように見えなくなります。
ブレースなしが受け入れられるように見えるのは、メソッドの開始時にパラメーターが変数をチェックするときだけです。
public int IndexOf(string haystack, string needle)
{
// check parameters.
if (haystack == null)
throw new ArgumentNullException("haystack");
if (string.IsNullOrEmpty(needle))
return -1;
// rest of method here ...
唯一の利点はコンパクトさです。次のことが明らかな場合、プログラマーは不要な {} をくまなく調べる必要はありません。
とはいえ、他の人が述べた理由により、私は常にプログラム ロジックに対して {} を使用します。中括弧を削除すると、そこにないときに精神的に簡単に固定し、微妙なコードの欠陥を導入するのは簡単すぎます。
H8ers は、私は独断的なルールの 1 つではありません。特定の状況では、特定の幅を超えない場合、実際にはコンパクトさを好みます。次に例を示します。
if(x > y) { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else { xEqualsY(); }
これは、次よりもはるかに読みやすいです。
if( x > y ){
xIsGreaterThanY();
}else if( x < y){
yIsGreaterThanX();
}else{
xEqualsY();
}
これには、ネストされた if-else ブロックにロジックをまとめ続けるのではなく、(私が行ったように) ロジックをメソッドに抽象化することを人々に奨励するという追加の利点があります。また、7 行ではなく 3 行を占めるため、複数のメソッドやその他のコードを表示するためにスクロールする必要がなくなる可能性があります。
if (x)
{
print "x is true";
}
同じ列でブレースの開始と終了を行うと、不一致のブレースを見つけやすくなり、ブロックを視覚的に分離できます。「if」と同じ列で括弧を開くと、ブロックが条件の一部であることを簡単に確認できます。中かっこだけを含む行によって作成されるブロックの周りの余分な空白により、コードをざっと読むときに論理構造を簡単に選択できます。中かっこを常に明示的に使用することで、後でコードを編集したときに、どのステートメントが条件の一部でどれがそうでないかを読み違えた場合の問題を回避できます。
followキーワードを使用して同じ行で中括弧を閉じるのは嫌いです。
if（x）{
print "x is true";
} そうしないと {
他のことをする;
}
これにより、else句だけを削除/コメントアウトすることが難しくなります。次の行にfollowキーワードを配置することで、たとえば、行の範囲を選択して、それらすべてを一度にコメント/コメント解除できるエディターを利用できます。
if（x）{
print "x is true";
}
//そうしないと {
//何か他のことをします;
//}
あなたがこのようなことをするなら：
if(x)
{
somecode;
}
else
{
morecode;
}
これは、長期間存続するコードのソース管理およびプリプロセッサディレクティブに対してより適切に機能します。誤ってステートメントを壊したり、余分な行を追加したりすることなく、＃ifなどを追加する方が簡単です。
慣れるのは少し奇妙ですが、しばらくするとかなりうまくいきます。
それが if の 1 行 (および必要に応じて else の 1 行) である場合、私は括弧を使用しないことを好みます。より読みやすく簡潔です。それは純粋に好みの問題なので、私はそれを好むと言います。常にブレースを使用しなければならないという基準を強制しようとするのはちょっとばかげていると思います.
誰かが if ステートメントの本文に別の行を追加し、(そのときのみ必要な) 中括弧を追加しないことを心配する必要がある場合は、サブビザンチン コーディング標準よりも大きな問題があると思います。
私はいつもこれを好みます：
if (x) doSomething();
if (x) {
doSomthing();
doOtherthing();
}
しかし、常に言語とあなたがしている行動に依存してください. 中括弧を付けたいときもあれば、付けたくないときもあります。コードにもよりますが、コーディングは 1 回書き、10 回書き直し、100 回読む必要があります。だから、あなたがしたいように、そしてあなたが読みたいように、もっと早く読んで理解したいと思うようにしてください
/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
return(0);
}else{
return(-1);
}
タブ以外の余分な空白を使用することはありませんが、常に括弧を含めることで時間を大幅に節約できます。
私はブラケット スタイルを好みます。これは主に、目に明確な開始点と終了点を与えるためです。これにより、ステートメントに実際に何が含まれているか、実際には if ステートメントであることが簡単にわかります。ちょっとしたことかもしれませんが、それが私がそれを使用する理由です。
所属するチーム内で一貫している限り、それほど重要ではありません
誰もが同じことをすることが重要です
ワンライナー if ステートメントを括弧で囲むと、後であなた (またはコードを保守または変更する他のコーダー) がその条件ブロックの一部にステートメントを追加する必要がある場合に、頭痛の種からあなたを保護するというかなりの正気の利点があります。
何があっても、これが私の行く道です！それは最高に見えます。
If(x)
{
print "Hello World !!"
}
Else
{
print "Good bye!!"
}
さまざまなコード書式設定スタイルの名前に興味がある場合は、ウィキペディアにIndent Stylesに関する記事があります。
これまでのところ、賛成票を投じているような気がしますが、次のいずれかを保証します。
if (expr) {
funcA();
}
else {
funcB();
}
または、読みやすさのために限られた場合の省略形：
if (expr) funcA();
else funcB();
私にとって、英語の文法のように読みたい場合は、速記形式が適しています。コードが十分に読みやすいように見えない場合は、次の行を分割します。
if (expr)
funcA();
else
funcB();
慎重に検討して、コーダー/コンパイラーのあいまいさを避けるために、ネストされた条件をif/ブロック内に配置しません。elseこれよりも複雑な場合は、ブロックifとelseブロックの両方に中括弧を使用します。
私は次の方が好きです...私はそれがよりきれいに見えると思います。
if(x)
{
code;
}
else
{
other code;
}
IDEがこの動作を強制することを望みます。あなたが正しく指摘したように、「正しい」行動はありません。一貫性がより重要です...それはどちらのスタイルでもかまいません。
私は自分が思っていたよりも外れ値だと思います。私はまだこれに気づいていません。
私はのファンです
if (x)
{ foo(); }
コンパクトで読みやすいように感じますが (中かっこが広すぎるのは嫌いです)、条件の範囲が明確になります。
また、単一行の if よりもブレークポイントに適しています。また、中かっこの改行の世界では、よりくつろいでいるように感じます。
if (x)
{ foo(); }
else
{
bar();
baz();
}
編集：元の質問を読み間違えたようですので、この回答はトピックから外れています。しかし、私はまだどんな反応にも興味があります。
提供されたオプションのうち、私は
if (x) {
print "x is true";
}
中括弧が入力する習慣になっているためです。
ただし、現実的には、ほとんどが Perl のプログラマーとして、私は以下を使用する可能性が高くなります。
print "x is true" if x;
（後置条件をサポートしていない言語で作業しているときは、いつもつまずきます。）
私は角かっこのない単一行ステートメントを好みます。新しいコード行を挿入するときにそれらを追加するのを忘れる危険性があることは知っていますが、最後にこれが起こったのはいつだったか思い出せません。私のエディター (vim) では、次のようなものを書くことができません。
if (x)
x = x + 1;
printf("%d\n", x);
インデントが異なるためです。私が問題を抱えていた唯一のことは、書かれたマクロが悪いことです:
#define FREE(ptr) {free(ptr); ptr = NULL;}
if (x)
FREE(x);
else
...
これはもちろん機能しませんが、フォーマット スタイルを変更する代わりに、マクロを修正して、これらの可能性のあるバグや問題を回避する方がよいと思います。
そのため、そのフォーマット方法には問題が発生する可能性がありますが、致命的ではありません。結局は好みの問題です。
emacs の if -- ブラケット マッチングと同じ行にブラケットを配置する最も有用な理由について誰も言及していません。終了ブラケットにカーソルを置くと、emacs は対応する開始ブラケットを含む行を表示します。開始ブラケットを独自の行に配置すると、機能が無効になります。
このタイプのフォーマットは問題ありません。理解しやすいものなので、人々はこれについてあなたと白黒で議論します。人々は、優れた設計や新しいアルゴリズムによる難しい問題の解決などのより大きな問題に対処するよりも、理解していることについて話すのが好きです。私は、単純なワンライナーにはブラケットなしを好む傾向があります。とはいえ、カッコつけて読んでいただけるのも嬉しいです。特定のプロジェクトに特定のスタイル ガイドがある場合は、それに従うことを好みます。私は、正しさの主観的な理想よりも一貫性を信じています。
ワンライナーに括弧を付けないという私の個人的な選択は、入力する文字数が少なく、コードが短く、簡潔であるためです。
1 つのライナーはまさにそれです... 1 つのライナーであり、次のように維持する必要があります。
if (param == null || parameterDoesNotValidateForMethod) throw new InvalidArgumentExeption("Parameter null or invalid");
たとえば、引数チェックのこのスタイルが好きです。コンパクトで、通常は読みやすいです。私は常にインデントされたコードに中かっこを入れていましたが、多くの些細なケースでは、モニター上のスペースを無駄にしているだけであることがわかりました。場合によっては中括弧を削除することで、メソッドの要点をより早く理解できるようになり、全体的なプレゼンテーションが見やすくなりました。ただし、それがさらに複雑になる場合は、他のすべてのように扱い、次のようにブレースを使用してすべてを行います。
if (something)
{
for(blablabla)
{
}
}else if
{
//one liner or bunch of other code all get the braces
}else
{
//... well you get the point
}
これは言われています...私は次のように同じ行の中括弧を軽蔑します:
if(someCondition) { doSimpleStuff; }
最悪の
if(somethingElse){
//then do something
}
よりコンパクトですが、ブレースを追跡するのが難しいと思います.
全体として、インデントとブレースに本当に奇妙な方法を採用しない限り、それは個人的な好みの問題です...
if(someStuff)
{
//do something
}
私にとっては、中かっこがあるとプログラムの流れが見やすくなります。また、if ステートメントの本体にステートメントを追加することも容易になります。中括弧がない場合は、中括弧を追加して別のステートメントを追加する必要があります。
中括弧を使用しないことの長所は、見栄えが良く、右中括弧で行を無駄にしないことだと思います。
行間隔とインデントは、読みやすさのために多くのことを行うことができます。
読みやすさに関しては、次のことを好みます。
// Do this if you only have one line of code
// executing within the if statement
if (x)
print "x is true";
// Do this when you have multiple lines of code
// getting executed within the if statement
if (x)
{
print "x is true";
}