中括弧なしでifステートメントを使用することは悪い習慣ですか?[閉まっている]


130

私はこのようなコードを見てきました:

if(statement)
    do this;
else
    do this;

しかし、これはもっと読みやすいと思います:

if(statement){
    do this;
}else{
    do this;
}

両方の方法が機能するので、これは単にどちらを使用するかという好みの問題ですか、それとも他の方法よりも推奨されますか?


1
の可能性のある複製中括弧を省略
nawfal 2014

私の意見では、それは悪いことです。なぜなら、ほとんど完全に一貫しているわけではない空白のインデントに依存し始めるからです。そのようなことを心配しなければならないとき、それは読者の思考の列を脱線させます。
Sridhar Sarnobat

回答:


212

最初のバージョンの問題は、中かっこを追加することを忘れずに戻ってifまたはelse句に2番目のステートメントを追加すると、コードが予期せずおかしい方法で壊れることです。

保守性に関しては、2番目の形式を使用する方が常に賢明です。

編集:ネッドはコメントでこれを指摘していますが、ここにもリンクする価値があると思います。これは単なる象牙の塔の架空のでたらめではありません:https : //www.imperialviolet.org/2014/02/22/applebug.html


17
そして、あなたは保守性のために常にコーディングすべきです。結局のところ、コンパイラはどちらの形式を使用してもかまわないと確信しています。ただし、愚かな中括弧のエラーが原因でバグが発生した場合、同僚はおびただしいかもしれません。
Esteban Araya

12
または、コードブロックに角括弧を使用しない言語を使用することもできます...
Tor Valamo

10
@ lins314159-いいえ、私はpythonが好きです。私はこの点で恥ずべきことだからです。
Tor Valamo、2010年

17
さらに証拠の間違いが起こる可能性があります(実際に起こります):imperialviolet.org/2014/02/22/applebug.html
Ned

8
SSLバグが中括弧を支持する議論であると主張することは不誠実です。それは、開発者が書くつもりであるかのようではなくif (…) { goto L; goto L; }、中括弧を忘れました。「もし(…){goto L; Lに移動します。} `はまだバグであるため(セキュリティに影響を与えるものではないため)、セキュリティバグではありません。別の例では、物事が反対方向に進み、ブレースレスコードが誤って安全になる可能性があります。3番目の例では、ブレースレスコードには最初はバグがなく、開発者はブレースを追加するときにタイプミスを導入します。
Pascal Cuoq 2014

112

ステートメントブロックを除外する際の1つの問題は、else-ambiguityです。つまり、Cに触発された言語はインデントを無視するため、これを分離する方法はありません。

if(one)
    if(two)
        foo();
    else
        bar();

これから:

if(one)
    if(two)
        foo();
else
    bar();

8
これは、上の回答で述べた問題(2番目のステートメントの追加)よりもはるかに深刻な問題です。

3
確かに、この答えは実際に私がこれらの答えを皮肉に読むことから、私が実際にこの間違いを犯したのではないかと穏やかに心配することへと私を導いた。
18

2
Cが実際にそれをどのように解釈するのか、他の誰かが疑問に思っている場合、GCCで行ったテストはこのコードを最初の方法で解釈します。tpcg.io/NIYeqx
オルタ

2
「あいまいさ」は間違った用語です。パーサーがこれをどのように認識するかについては、あいまいさはまったくありません。elseバインドは、最も内側の最も内側に貪欲にバインドしifます。これを知らない、それについて考えていない、またはまだ十分なコーヒーを持っていない人々によってCまたは類似の言語がコーディングされている場合に問題が発生します。したがって、彼らは1つのことをすると思うコードを記述しますが、言語仕様によると、パーサーは別のことを行う必要がありますが、これは非常に異なる場合があります。そしてはい、それは文法がそれらを理論的に「不必要」としてフラグを立てたとしても、常に中括弧を含めることを支持する別の堅実な議論です。
underscore_d

35

私の一般的なパターンは、1行に収まる場合は次のようにします。

if(true) do_something();

else句がある場合、または実行したいコードtrueが非常に長い場合は、中括弧で囲みます。

if(true) {
    do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}

if(false) {
    do_something();
} else {
    do_something_else();
}

最終的には、スタイルと読みやすさの主観的な問題に帰着します。ただし、一般的なプログラミングの世界は、2つの部分(中かっこを使用する言語の場合)にかなり分かれています。例外なしで常に使用するか、例外付きで使用するかです。私は後者のグループの一員です。


4
書くのは簡単ですがif(true){ do_something(); }、なぜ別のプログラマーが深刻なバグを導入する可能性があるのか​​(Appleの「goto fail」の合計sslコードのねじ込みを調べてください)。
クレイグ、

9
ブラケットがいくつあっても、メンテナーが頭を使うことから解放されません。「1行に収まる場合は括弧なし」という考えを支持します。なぜなら、私にとって、このようなifは、3項のif演算子のバージョンであり、三項。そして、なぜ誰かが三項に括弧を導入するのですか?
Michal M

最終的にそれが主観的であることや、スタイルと読みやすさにのみ影響することにはまったく同意しません。判明した問題のデバッグに時間を無駄に費やした人は、ブロック区切り文字が欠落している(その欠落に気付かない)ために発生したため、私は「不要」な場合にそれらを省略するコーディングスタイルを使用する必要があり、多くの人が読んだこのようなコーディングスタイルによって引き起こされる恐ろしいバグは、間違いなく非常に客観的で実用的な問題だと思います。確かに、区切り記号を強制するスタイルがあっても、それらを忘れることはできますが、確かに-少なくとも-筋肉の記憶は私たちをはるかに可能性が低くします。
underscore_d

10

使用しているIDEのコードフォーマッタを使用しています。それは異なる場合がありますが、設定/オプションで設定できます。

私はこれが好きです:

if (statement)
{
    // comment to denote in words the case
    do this;
    // keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
    do this;
}

5
これは完全に主観的なスタイルの問題であり、私はブレースのみのラインの冗長性が個人的に好きではありません。しかし、ちょっと。
Matchu

14
私はこのスタイルをサポートしています。ほとんどの人は左から右にコードを読み、それは一種の目を画面の左端に固定します。コードを視覚的に分離し、ステップの論理ブロックに抽出するのに役立ちます。
mloskot 2010年

6
私はいつもこのスタイルを好みました。対応する右括弧を見つけるのははるかに簡単です。だから、それはたくさんのスペースを取りますか?小さいフォントを使用してください。
火曜日

4
中括弧が別々の行にある場合、コードを「スキャン」する方が常に簡単だと思います。それはすべてに当てはまります。クラス、メソッド、if-とwhileステートメントなど。同じ行に最初のブレースを付けるのは好きではありません...
Svish

2
特に、折りたたみ可能なコードIDEがある場合、空白は安価です。
Moo

10

私が従う「ルール」はこれです:

「if」ステートメントが何かを行うためにテストしている場合(IE呼び出し関数、変数の構成など)、中かっこを使用します。

if($test)
{
    doSomething();
}

これは、どのような状況で、どの関数が呼び出され、プログラムのフローがどこに向かっているのかを明確にする必要があると感じているからです。どのような関数が呼び出され、どのような変数がこの条件に設定されているかをプログラマーに正確に理解させることは、プログラムが何をしているのかを正確に理解させるために重要です。

「if」ステートメントが何かを停止するためにテストしている場合(ループまたは関数内のIEフロー制御)、1行を使用します。

if($test) continue;
if($test) break;
if($test) return;

この場合、プログラマーにとって重要なことは、コードを実行したくない例外的なケースをすばやく発見することです。これはすべて、実行ブロックではなく$ testでカバーされます。


8

ブレースを最初から正しくすることで、これをデバッグする必要がなくなります。

if (statement)
     do this;
else
     do this;
     do that;

1
それは認められた理論的根拠のようですが、(ここで悪魔の支持者を演じるために)1つの行を保存しながら、単一の追加の構文強調表示ルールもこれを解決しませんか?
Ken

2
したがって、ヒットしたときにインデントを修正するIDEがあります;:)
Sam Harwell

6

単純なものも含めて、すべてのifステートメントに中括弧を使用します。または、三項演算子を使用するように単純なifステートメントを書き換えます。

if (someFlag) {
 someVar= 'someVal1';
} else {
 someVar= 'someVal2';
}

このようにはるかによく見えます:

someVar= someFlag ? 'someVal1' : 'someVal2';

ただし、if / elseブロックに入力する必要があるものが他にないことが確実である場合にのみ、3項演算子を使用してください。



2

私の経験から、最初のフォームの(非常に)わずかな利点はコードの可読性であり、2番目のフォームは「ノイズ」を追加します。

しかし、最近のIDEとコードの自動生成(またはオートコンプリート)では、2番目の形式を使用することを強くお勧めします。中括弧を入力するのに余分な時間を費やすことはなく、最も頻繁に発生するバグのいくつかを回避できます。

十分なエネルギーを消費するバグがあり、人々は大きな時間の無駄のためにドアを開けるべきではありません。

コードを書くときに覚えておくべき最も重要なルールの1つは一貫性です。誰が書いたかに関わらず、すべてのコード行は同じように書かれるべきです。厳密であることにより、バグが「発生」するのを防ぎます;)

これは、変数、メソッド、ファイルに明確かつ明示的に名前を付けたり、正しくインデントしたりすることと同じです...

私の学生がこの事実を受け入れると、彼らは自分のソースコードとの戦いをやめ、コーディングを非常に興味深く刺激的で創造的な活動と見なし始めます。彼らは神経ではなく心に挑戦します!


2

それは好みの問題です。私は個人的に両方のスタイルを使用しています。これ以上ステートメントを追加する必要がないと合理的に確信している場合は、最初のスタイルを使用しますが、可能であれば2番目のスタイルを使用します。最初のスタイルにこれ以上ステートメントを追加することはできないので、一部の人々がそれを使用することを推奨しないと聞いています。ただし、2番目の方法では追加のコード行が発生するため、ユーザー(またはプロジェクト)がこの種のコーディングスタイルを使用する場合、最初の方法は単純なifステートメントに非常に適しています。

if(statement)
{
    do this;
}
else
{
    do this;
}

ただし、この問題の最善の解決策はPythonであると思います。空白ベースのブロック構造では、ifステートメントを作成する方法が2つありません。1つしかありません。

if statement:
    do this
else:
    do this

これには中括弧をまったく使用できないという「問題」がありますが、最初のスタイルよりも行が少なくなり、ステートメントを追加できるという利点があります。


私自身、Pythonがif-elseステートメントを処理する方法は非常に醜いと思いますが、それでも、私は(まだ)Pythonプログラマではありません
ヘルパーメソッド

1

私は常に自分のコードを標準化し、できるだけ同じに見えるように努めてきました。これにより、他の人が更新を担当しているときに簡単に読むことができます。最初の例を実行し、途中で行を追加すると失敗します。

動作しません:

if(statement)これを行う; この; それ以外の場合はこれを行います。


1

個人的には、最初のスタイルを使用して、例外をスローするか、メソッドから時期尚早に戻ります。関数の最初の引数のチェックと同様に、これらの場合、私がすることはめったにありませんし、他にできることはほとんどありません。

例:

if (argument == null)
    throw new ArgumentNullException("argument");

if (argument < 0)
    return false;

それ以外の場合は、2番目のスタイルを使用します。


1

私の個人的な好みは、次のように空白と括弧を組み合わせて使用​​することです。

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

これは見た目がきれいで、コードが非常に読みやすくなり、最も重要なのはデバッグです。


0

私は、コードで明示し、中括弧を使用する方がよいという事実において、ほとんどの回答に同意します。個人的には、一連のコーディング標準を採用し、チームの全員がそれらを知って準拠するようにします。私が作業している場所では、.NETプロジェクト用にIDesign.netによって公開されたコーディング標準を使用しています。


0

中かっこを付けることをお勧めします。しかし、時々、三項演算子が役立ちます。

の代わりに :

int x = 0;
if (condition) {
    x = 30;
} else {
    x = 10;
}

単に行う必要があります: int x = condition ? 30 : 20;

また、ケースを想像してみてください:

if (condition)
    x = 30;
else if (condition1)
    x = 10;
else if (condition2)
    x = 20;

あなたが中かっこを入れればそれははるかに良いでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.