web-dev-qa-db-ja.com

return ..およびデフォルトでケースを分割

OCDを使用すると、caseステートメントを実行するときに、実行されなくても、「ブレーク」が追加されます。次のコード例を検討してください。

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

私の2つの質問は次のとおりです。
「ケース2」の場合、休憩は本当に必要ありませんが、とにかくそこに置くことは良い考えですか？ 「デフォルト：」の場合。それは純粋にOCDですか、それともここで休憩をとる本当の理由はありますか？

ccoding-styleswitch-statement
39
Alan H

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

35
James Thompson

私は最終的なデフォルトのケースで中断することに同意し、返品後の中断には同意しません。 （同僚がそれをやっていて、目が痛い。）

また、スイッチをインデントして、インデントレベルの急増を抑えています。 :)つまり：

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

（また、returnステートメントは関数ではないため、余分なスタイルを強制して1つのスタイルに見せることは適切ではないと思います。）

25
chaos

デフォルトのケースの後の中断は、単に個人的な好みの問題です。

帰国後に休憩をとることは、私にはほとんど矛盾しているようです。 returnステートメントを本当に目立たせるために、改行を削除します。

8
samoz

復帰後の中断は不適切な形式であると考えます。一部のコンパイラでは到達できないコードに関する警告が表示されます。

デフォルトのケースのブレークは完全に適切であり、ケースフォールスルーはツールであり、使用時に特にマークする必要があります。

2
Don Neufeld

私は常にcasedefaultを含めてそれぞれに改行を入れて、switchの中でreturnを実行しないようにします。 2〜3ケースの短いスイッチ（デフォルトを含む）の場合、returnは問題ありませんが、すべてのcaseが同じ方法である場合のみです。 「無意味な」ブレイクは無意味だと思い、読むコードを増やすだけです。壊れるだけの完全に無意味な空のデフォルトにも同じことが言えます。私の意見では、コードを読みやすくすることは、誰かがこれを変更した場合に何が起こるかよりも重要です。

2
Joakim Elofsson

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

個人的には、私は通常、リターンがある場合はそれらを省略しますが、可能であれば、関数内に複数のリターンポイントが存在しないようにします。

しかし、私はdefault:大文字小文字の区別-理由の1つ：省略した場合、デフォルトの後に誰かが新しい大文字小文字を追加した場合：ブレークを追加するのを「忘れた」場合の動作は異なります。

1
Reed Copsey

他の人が指摘したように、復帰後またはデフォルトの場合の休憩は、ほとんどの場合個人的なスタイルの問題です。

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

 switch（foo）{
 case 0：
 baz = 1; 
 break; 
 case 1：
 bar％= 2; 
 return -1; 
/* NOTREACHED */
 case 2：
 bar = -1; 
 return -2; 
/* NOTREACHED */
 break; 
 default：
 break; 
}

ケース1と2の間では、私は2を好む傾向があります。コメントにNOTREACHEDと書かれていても、コードが変更されると、コメントが（意図せずに）嘘をつく可能性があります。 NOTREACHEDコメントは、自分が何をしているのかを知っているlintを満たし、関数を早期に終了することを思い出させるので、気に入っています。返品が削除された場合、返品の後に休憩を置くとエラーが軽減されるという推論は、私には欠陥があるように思えます。次のケースに陥るか、スイッチを終了して以前のように続行するかに関係なく、依然として偽の動作をすることになります。

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

1
Erik

他の人が、誰かが後で来て、その後にケースを追加する場合に備えて、デフォルトのケースに休憩を残すと述べたコメントについて：コーディング標準はalwaysにデフォルトを最後のケース;そのため、私たちの状況では、その場合の中断は冗長です。 （これは、私が会社のコーディング標準に完全に同意する1つのケースです。デフォルトのケースは常に最後のケースなので、長いswitchステートメントでも、どこにあるかを常に知っています。）

リターン後のブレークについては、リターンしない実行パスがない限り、ブレークを省く傾向があります。 （これに対する私の例外は、ケースにいくつかの実行パスがあり、コードのクイックスキャンですべてが返されるかどうかわからないことがまれにある場合です。安全である。）

1
RobH

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

1
Broken_Window

この正確な例では、どちらの質問でも、個人的な好みです。一般に、ルールはこれです。ブレークのないものはすべて通過します。つまり、（ポッドが言ったように）デフォルトのケースが中断しない場合に備えて、デフォルトのケースにブレークを入れるのは良い考えです。これは、ケースに返品が含まれている場合、次の中断は実際には必要ないことも意味します。

0
trh178

私は個人的に休憩を入れていませんが、誰かがリターン（-1）をスイッチの外側に移動することを決定し、休憩を追加するのを忘れた場合に役立ちます。

0
Jimmy

私はあなたが次のケースに陥るつもりはないことを示すために休憩を入れます。

0
Maggie