c - return.. とデフォルトのケースでブレーク

Question

私の OCD では、case ステートメントが実行されない場合でも、case ステートメントを記述するときに「ブレーク」を追加する必要があります。次のコード例を検討してください。

switch(option) {
    case 1:
        a = 1;
        b = 7;
        break;
    case 2:
        a = 2;
        b = 4;
        return (-1);
        break;
    default:
        a = -1;
        break;
}

私の 2 つの質問は次のとおり
です。「デフォルト:」の場合。それは純粋にOCDですか、それともここで休憩する本当の理由はありますか?

score 36 · Accepted Answer

どちらも休憩する必要はありませんが、持っていても害はありません。私の意見では、コードを構造化することは、いくつかの無関係なステートメントを持つ価値があります。

score 26 · Accepted Answer

私は最終的な不履行の場合に中断することに同意しますが、返品後の中断には同意しません。（同僚がやっていて、目が痛いです。）

また、インデントレベルの増殖を減らすためにスイッチをインデントします。:) すなわち:

switch(option) {
case 1:
    a = 1;
    b = 7;
    break;
case 2:
    a = 2;
    b = 4;
    return -1;
default:
    a = -1;
    break;
}

(また、return 文は関数ではないので、それを関数のように見せる余分なスタイルを強制するのは適切ではないと思います。)

score 8 · Accepted Answer

デフォルトのケースの後の休憩は、個人的な好みの問題です。

復帰後に休憩を入れることは、私にはほとんど矛盾しているように思えます。returnステートメントを本当に目立たせるために、ブレークを削除します。

score 2 · Accepted Answer

デフォルトを含む各ケースで常に休憩を取り、switch内で return をまったく実行しないようにすることを好みます。2 ～ 3 ケース (デフォルトを含む) だけの短いスイッチの場合、戻り値は問題ありませんが、すべてのケースが同じ方法で行われる場合に限ります。「無意味」な休憩は無意味であり、読むコードが増えるだけです。同じことが壊れるだけの空のデフォルトにも当てはまり、まったく無意味です。私の意見では、コードを読みやすくすることは、誰かがこれまたはそれを変更した場合に何が起こるかよりも重要です。

score 2 · Accepted Answer

return 後の break は悪い形式であると考えます。一部のコンパイラでは、到達できないコードに関する警告が表示されます。

デフォルトのケースの中断は完全に適切です。ケースのフォールスルーはツールであり、使用する場合は特に注意する必要があります。

score 1 · Accepted Answer

C、C ++、java、C＃では、これらの「ブレーク」を入れないと、プログラムコードフローは他の「ケース」に分類され、変数がそうであるかどうかに関係なく、それらの内部の命令を実行すると言われています。「ケース」に値が割り当てられていません。

score 1 · Accepted Answer

他の人が指摘しているように、復帰後またはデフォルトの場合にブレークを配置することは、主に個人的なスタイルの問題です.

特定のスタイルルールに従う必要がない場合は、次のようなものを好みます。

    スイッチ（フー）{
         ケース 0:
             バズ= 1;
             壊す;
         ケース 1:
             バー %= 2;
             -1 を返します。
             /* 届いていない */
         ケース 2:
             バー = -1;
             -2 を返します。
             /* 届いていない */
             壊す;
         デフォルト：
             壊す;
    }

ケース 1 と 2 の間では、私は 2 を好む傾向があります。コメントに NOTREACHED と書かれていても、コードが変更されると、(もちろん意図せずに) コメントが嘘をつく可能性があります。私は NOTREACHED コメントが好きです。これは、自分が何をしているのかを知っているという lint を満足させることができ、関数を早期に終了することを思い出させるのに役立つからです。リターンの後にブレークを配置すると、リターンが削除された場合にエラーが軽減されるという理由には、私には欠陥があるように思えます。次のケースに失敗するか、スイッチを終了して以前と同じように続行するかに関係なく、依然として偽の動作が発生します。

もちろん、それを避けることができれば、スイッチの本体内の関数から戻ることはありません。

score 1 · Accepted Answer

誰かが後で来て、その後にケースを追加した場合に備えて、デフォルトのケースに休憩を残すという他の人のコメントについて：私が働いている場所では、コーディング標準は常にデフォルトを最後のケースとして配置するように言っています。したがって、私たちの状況では、その場合の休憩は冗長です。(これは、私が会社のコーディング標準に心から同意する 1 つのケースです。デフォルトのケースが常に最後のケースであるため、長い switch ステートメントであっても、どこにそれを見つけるかを常に知っているからです。)

リターン後のブレークについては、リターンしない実行パスが無い限り、余計だと思うので省略しがちです。（これに対する私の例外は、ケースに複数の実行パスがあり、コードをすばやくスキャンしてもそれらがすべて返されるかどうかがわからないというまれなケースです。その場合は、ブレークをそのままにしておきます安心してください。）

score 1 · Accepted Answer

どちらの休憩もあなたには何もしませんが、どちらも害はありません。

個人的には、リターンがある場合は通常それらを除外しますが、可能であれば、関数に複数のリターンポイントを持たないようにしています。

ただし、ケースのブレークは良いと思います-1default:つの理由から:それを省略し、デフォルトの後に誰かが新しいケースを追加した場合、ブレークに追加するのを「忘れた」場合、動作は異なります.

score 0 · Accepted Answer

0

次のケースに進むつもりがないことを示すために、休憩を入れます。

于 2009-06-05T17:21:38.840 に答える

score 0 · Accepted Answer

私は個人的にブレークを入れませんが、他の誰かがリターン (-1) をスイッチの外側に移動することを決定し、ブレークを追加するのを忘れた場合に役立つ可能性があります。

score -1 · Accepted Answer

私の限られた知識で申し訳ありませんが、OCDとは何ですか?
それとは別に、Brian Kernighan は、ステートメント内でいつ使用すべきか (すべきでないか)について適切な説明を提供しています。breakswitch

c - return.. とデフォルトのケースでブレーク

13 に答える 13

Related

Reference