web-dev-qa-db-ja.com

スイッチのデフォルトのケースで中断

最後のケースの後にbreakを含めるかどうか、常にdefaultを含めるのは少し困惑しています。

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

        break; // Is it considered to be needed?
}

breaksの唯一の目的は、残りのswitch- caseでコードが実行されないようにすることです。

次に、一貫性のためにbreakを最後に持つこと、またはbreakが機能的使用をまったく適用しないためにそれをスキップすることは、より論理的であると考えられますか？私の意見では、どちらも論理的には異なっています。

これは、.phpファイルを?>で終了することとある程度比較できます。私は?>で終わることはありませんが、そのほとんどは空白スペースを出力するリスクがあるためです。

programming-practicesswitch-statement
91
Robin Castlin

breakは、最後の選択肢の後には技術的に必要ありません（これは、defaultである必要はありません。完全に合法であり、default分岐先）;コードがswitchステートメントの最後を通過するか、最後のブランチの最後でbreaksがアウトになるかは、同じ結果になります。

ただし、次の3つの理由により、最後のブランチを含むすべてのブランチをreturnまたはbreakステートメントで終了します。

  1. リファクタリング。すべてのブランチがbreakまたはreturnで終わっている場合、意味を変更せずにブランチを並べ替えることができます。これにより、そのような並べ替えで回帰が発生する可能性が低くなります。
  2. 一貫性、そして最小の驚き。一貫性とは、実際に意味が異なる場合を除いて、ブランチは一貫して終了する必要があるということです。最小サプライズの原則では、類似のものは類似して見えるはずであると規定しています。 switchブロックの最後のブランチを前のブランチとまったく同じように終了すると、両方が満たされ、読みやすく、理解しやすくなります。明示的なbreakを省略した場合、最後のブランチは光学的に異なります（これはクイックスキャンで特に重要です）。それが実際に異なっていないことを確認するために、リーダーは要点に降りる必要があります。個々のステートメントを読むことの骨の折れるレベル。
  3. 身を守る。すべてのswitchブランチをbreakで終了する習慣をつけると、しばらくすると自動的に分岐し、重要な場所で誤ってそれを忘れてしまう可能性が低くなります。すべてのブランチの終わりにbreakを期待するように自分自身をトレーニングすると、不足しているbreakステートメントを検出するのにも役立ちます。これは、デバッグとトラブルシューティングに最適です。
147
tdammers

ほとんどの言語でのswitch-caseの使用に関する曖昧さを考慮して、それを使用する場合明示的に、および意図的に望まない場合を除いて、常にbreakステートメントを使用することをお勧めします。

これは、一部の理由により、すべてのcase呼び出しが同じように見えるため、私の意見では読みやすさが向上するためです。しかし、それはまた、誰か（あなたでも）が後の最後のブロックの後にcaseを挿入することを選択した場合、前のブロックをチェックすることを気にする必要がないため、追加時のバグを減らすのに役立ちます新しいコード。

12
user69037

lastの場合、breakは必要ありません。 Wordは "last"（ないdefault）を使用します。これは、デフォルトのケースが最後のケースである必要がないためです。

_switch(x)
{
case 1:
//do stuff
break;

default:
//do default work
break;

case 3:
//do stuff

}
_

また、2つの連続するbreaksの間にはcaseが必要です。時々、他の人が私のコードを参照するときに読みやすくするために、私のコードでif(a!=0)を使用します。 if(a)を使用することを選択できます。これは私の選択の問題です

1
Suvarna Pattayil