ブロックifの単一ステートメント-中括弧またはno？[閉まっている]

どちらが良い/より一般的に受け入れられていますか？

この：

if(condition)
{
  statement;
}

または：

if(condition)
  statement;

私は最初のものを好む傾向があります。実際にifブロックに属するものを簡単に伝えることができ、他の人が後で括弧を追加する（または忘れてバグを作成する）のを防ぎ、すべてのifステートメントを作成するためです中括弧のあるものとないものの代わりに均一。ただし、2番目のものはまだ構文的に正しく、間違いなくよりコンパクトです。どちらがより一般的に他の人に好まれているかを知りたいのですが。

2番目はエラーが発生しやすいため、最初の方が優れています。たとえば、何かをデバッグするために一時的にコードをコメントアウトしているとしましょう：

if(condition) 
//      statement;
otherStatement;

または、急いでコードを追加します。

if(condition) 
    statement;
    otherStatement;

これは明らかに悪いことです。一方、最初の人は時々冗長に感じます。したがって、十分に短く単純な場合は、すべてを1行に配置することを好みます。

if(condition) statement;

これにより、構文上のノイズが削減され、コンストラクトが実際に実行されるように見えるため、エラーが発生しにくくなります。この構文が非常に単純で短い条件とステートメントにのみ使用されるとすれば、完全に読みやすくなります。

私は常に安全のためにブラケットを使用しています。

あなたがそれを書くとき、それは問題ありませんが、誰かが将来やって来て、それを括弧で囲まずに別のステートメントを挿入することを知っています。

可能であれば、括弧なしのバージョンを好みます。

以下の説明は長めです。どうか我慢してください。このスタイルを好む理由を説得します。また、通常の反論が成り立たないと思う理由も説明します。

（近く）空の行は無駄です

この理由は、閉じ括弧には余分なコード行が必要であり、スタイルに応じて開き括弧も必要なためです。¹

これは大したことですか？表面的には、ありません。結局のところ、ほとんどの人はコードに空行を入れて論理的にわずかに独立したブロックを分離するため、読みやすさが大幅に向上します。

しかし、私は垂直スペースの浪費を嫌います。最新のモニターには、実際には十分な水平スペースがあります。しかし、垂直方向のスペースはまだ非常に限られています（直立したモニターを使用する場合を除き、これは珍しいことではありません）。この限られた垂直方向のスペースが問題です：個々のメソッドはできるだけ短くする必要があり、対応するブレース（または他のブロック区切り記号）は画面の高さの差以下でなければならず、ブロック全体が表示されないことが広く認識されていますスクロール。

これは根本的な問題です。画面上でブロック全体が表示されなくなると、把握が複雑になります。

結果として、冗長な空の行を嫌います。独立したブロックを区切るために単一の空行が重要である場合（このテキストの視覚的な外観を見てください）、連続した空行は私の本では非常に悪いスタイルです（そして、私の経験では通常、初心者プログラマーのサインです）。

同様に、単にブレースを保持し、節約できる可能性のあるラインもそうでなければなりません。中括弧で区切られた単一ステートメントブロックは、1〜2行を無駄にします。画面の高さあたり50本の線だけで、これは顕著です。

中かっこを省略しても害はありません

中かっこを省略することに対する引数が1つだけあります。誰かが問題のブロックに別のステートメントを後で追加し、中かっこを追加するのを忘れて、コードのセマンティクスを不注意に変更するということです。

これは確かに大したことでしょう。

しかし、私の経験ではそうではありません。私はずさんなプログラマーです。それでも、プログラミングの10年間で、シングルトンブロックに余分なステートメントを追加するときに中かっこを追加することを忘れたことは一度もありません。

これはよくある間違いであると信じることさえできません。ブロックはプログラミングの基本的な部分です。ブロックレベルの解決とスコーピングは、プログラマーにとって自動的に根付く精神的なプロセスです。脳はそれを行うだけです（そうでなければ、プログラミングについての推論はずっと難しくなります）。中括弧を置くことを覚えておくために必要な追加の精神的な努力はありません。プログラマーは、結局、新しく追加されたステートメントを正しくインデントすることも覚えています。そのため、プログラマーはブロックが関係していることをすでに精神的に処理しています。

今、私はいない括弧を省略すると、ミスを起こさないことを言って。私が言っているのは、何らかの形で証拠がないということです。私たちは、単に知らない、それが害を引き起こすかどうか。

だから誰かが科学実験から集められたハードデータを見せて、これが実際に問題であることを証明するまで、この理論は「まあまあの物語」のままです。なければならない引数として使用します。

¹この問題は、ブレースを含むすべてを同じ行に置くことで解決される場合があります。

if (condition)
{ do_something(); }

しかし、ほとんどの人がこれを軽deしていると言っても安全だと思います。さらに、中括弧なしのバリアントと同じ問題があるため、両方の世界で最悪です。

二番目に行きます。簡潔で冗長ではありません。

私は最小公分母に書かないようにしているので、他の開発者が今日のプログラミングで最も一般的な制御フロー構造の1つを書く方法を知っていることを期待しています。

私は以下を使用します（ここでのコンセンサス）：

if (condition) {
    any_number_of_statements;
}

また可能：

if(condition) single_compact_statement;

特にC / C ++のような言語ではあまり良くありません：

if(condition) 
    single_compact_statement;

（Pythonでの選択はありません;-)

Perl、あなたが使用したいです：

$C = $A**3 if $A != $B;

または

$C = $A**3 unless $A == $B;

（これは擬似コードではありません ;-)

中かっこを使用します-上記のすべての理由に加えてもう1つ。

コードのマージ。自動マージによって壊れた単一ステートメントifで作業したプロジェクトで発生することが知られています。恐ろしいのは、コードが間違っていてもインデントが正しく見えるため、このタイプのバグを見つけるのは難しいことです。

だから私は中括弧で行く-彼ら自身の行に。そのようにレベルを見つけるのは簡単です。はい、それは垂直スクリーンの不動産を無駄にします、そしてそれは本物の欠点です。バランス上、しかし、私はそれが価値があると思います。

中括弧なし。他のプログラマーが私のコードに2番目のステートメントを追加した場合、誰かが私の車を運転させて、彼らが崖を越えたのと同じくらい私のせいではありません。

ここでこの議論を複数回行ってきましたが、全体的なコンセンサスは常に中括弧を使用することです。主な理由は、読みやすさ/保守性に関するものです。

ifブロックにコードを追加する必要がある場合は、中括弧を覚えたり検索したりする必要はありません。将来のプログラマがコードを読むとき、中括弧は常に明確です。

プラス面として、ReSharperはVisual Studioの怠zyなプログラマーにブレースを自動的に追加します。他のIDEにも同様に追加するアドオンがあると思います。

ほとんど例外なく、最初の構文を使用します。誤解されないからです。

「私に考えさせないでください」はユーザーインターフェイスだけに当てはまりません、y'all ;-)

個人的には2番目の方が好きです。最初のものはく、扱いにくく、水平方向のスペースを無駄にします。2番目の問題の主な問題は、マクロと、後でコードを修正する人が間違っていることです。

これに対して、「マクロを使用しない」と言います。また、「いまいましいコードを正しくインデントします」と言います。プログラミングに使用されるすべてのテキストエディタ/ IDEが自動的にインデントを行う方法を考慮すると、これはそれほど難しくないはずです。Emacsでコードを書くとき、自動インデントを使用して、前の行に何か間違ったことを書いたかどうかを識別します。Emacsがインデントを台無しにしたときはいつでも、私は通常、何か間違ったことをしたことを知っています。

実際には、私が自分の前に設定したコーディング規約に従っています。しかし、これらは私をイライラさせます（そして、Pythonでコーディングし、この大惨事全体がなくなったとき、私はより幸せになります）：

if (condition) {
    statement;
} // stupid extra brace looks ugly

それから

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

正直なところ、ifステートメントの2つのステートメントは、1つのステートメントよりもはるかに悩ましいものです。ほとんどの場合、括弧が必要であり、ifステートメント内の2つのステートメントだけではおかしく見えます。

中括弧なしの2行バージョン（2番目の形式）を使用しますが、スペースを節約するためではありません。

このフォームを使用するのは、読みやすく、視覚的に魅力的で、入力しやすいからです。これらの条件が満たされている場合にのみ、このフォームを使用します。つまり、if条件は1行にうまく収まる必要があり、対応するステートメントは次の行にうまく収まる必要があります。そうでない場合は、中括弧を使用して読みやすくします。

このフォームを使用する場合、ifステートメントの前後（またはコメントが存在する場合はコメントの上）に空行（または中括弧のみを含む行）があることを確認します。これは私が意識的に従うルールではありませんが、この質問を読んだ後に気づきました。

画面スペースの節約は私にとって優先事項ではありません。もっとスペースが必要な場合は、より大きなモニターを使用します。私の画面はすでに、私が注意を向ける必要があるかもしれないものを読むのに十分な大きさです。私が画面全体を占めるほど多くのコード行に一度に集中する必要があるとは考えにくい。一度に多くのコードを表示しないと理解できないコードの塊でネストが進行している場合、リファクタリングによってロジックをより適切に表現できるかどうかを検討する必要があります。

以下は、この形式のifステートメントの使用方法を示すいくつかの例です。

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

中かっこ。常に。私はそれらのファンのようなものです。コードに一貫性を与えるからです。また、@ dsimchaが書いたように、コードの追加行でエラーが発生する可能性が低くなります。

コードの単一行を囲むブレースの「Uさ」は、デバッグやコードの追加を伴う場合に発生する可能性のある追加作業よりも有害ではありません。

個人的にはブラケットを使用します。

どうして？

誰かがやって来てifステートメントにコードを追加する必要がある場合、スコープがどこにあるかは100％明確です。

ifブロック内にステートメントがいくつあっても、ステートメントの形式を一貫させます。

ただし、プロジェクトのスタイルをそのままにする場合は、それに固執します。

ほとんどの場合、安全のためにブラケットを使用しています。ただし、ブロックの内容が本当に短い場合は、それらをオフにして、次のようにワンライナーにします。

if (x==5) Console.WriteLine("It's a five!");

一貫性を保つためにブレースを好みますが、余白をあまり無駄にしません（したがって、読みやすい形式のコードが私の限られた視野にあります）。だから私はこれを十分に短い行のために書いています：

If (cond) { statement; }

私は通常中括弧を使用しますが、使用しない場合もあります。

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

私にとっては、そこに追加するのはばかげているだけです。の後に誰かが文を追加するとreturn、スコープの問題よりも大きな問題が発生します。

IDEで利用可能なコードフォーマットがある場合、ブレースを使用しません。

一方、自動フォーマットをサポートしない他のエディターでコードを編集する可能性がある場合、他の投稿で言及されているように中括弧を入れないことは危険です。しかし、それでもブレースを使用したくないので、問題ありません。