スイッチのデフォルトケースでブレーク

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

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

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

break唯一の目的は、コードが残りのswitchケースを実行しないようにすることです。

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

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

break最後の選択肢の後、技術的には必要ありません（あなたは、そうである必要はありませんdefault：それは完全に合法であり、時にはdefaultブランチを最初に置くことさえ有用です）; コードがswitchステートメントの終わりまで落ちるか、breaks最後のブランチの終わりに出るかは同じ結果になります。

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

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

switch-caseほとんどの言語での使用に関する曖昧さを考えると、それを使用するbreakときは、明示的かつ設計上望ましくない場合を除き、常にステートメントを使用することをお勧めします。

これは、すべてのcase呼び出しが同じように見えるためです。しかし、誰かが（あなたでさえ）case後の段階で最後のブロックの後に挿入することを選択した場合、前のブロックをチェックすることに気を配る必要がないことも意味します。

最後のケースのbreak後は必要ありません。私は「last」（デフォルトではない）という言葉を使用します。これは必要ではないため、デフォルトのケースは最後のケースです。

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

default:
//do default work
break;

case 3:
//do stuff

}

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