このスイッチのステートメントは悪いですか？私の意見で

Question

Switch(some case) { 
    case 1: 
      // compute something ... 
      return something; 
      break; 
    case 2: 
      // compute something ... 
      return something; 
      break; 

/* some more cases ... */ 

    case X: 
      // compute something ... 
      return something; 
      break; 
    default: 
      // do something 
      return something; 
      break; 
} 

：

このswitch文は、リターン正当であるとちょうどdoesntの右に見えるか、右に感じる破ると仮定。

ブレークは明らかに重複していますが、省略形が貧弱です（または、この貧弱なスタイルが最初から始まっていますか？）。

---

私は個人的にこれを行ういけないが、仕事でのコードベースでは、このうちのいくつかはあります。そして、いいえ、私は独善になるつもりはなく、コードベースを修正してください。

Answer 1

C＃コンパイラは、ブレークが到達不能コードであることを通知すると警告を出します。だから私の本では、復帰と休憩の両方を持つのは悪い形です。

Answer 2

私の意見では、私は 'break'キーワードを省略します。私は個人的に、「実行が終了しました！これ以上見ることはありません！ ' -が悪いスタイルです含める

switch(some case) { 
    case 1: 
      // compute something ... 
      break; 
    case 2: 
      // compute something ... 
      break; 
/* some more cases ... */ 
    case X: 
      // compute something ... 
      break; 
    default: 
      // do something 
      break; 
} 
return something; 

Answer 3

は、私は小さな変更になるだろう。それらは到達不能なステートメントです。それらを取り除く。

私は、ローカル変数を設定してからちょうど戻り値を返す代わりに、ケースが直接返されるのが好きです。つまり、のコードを読んでいるときにはそれが信じられないほど明確です。つまり、は、それだけです。最初の場所でのスイッチングの面で

余談：switch文を使用すると、ここで行うには正しいことであるかどうかについては

、それは実際に他のものに依存します。代わりに多態型を使用するのは理にかなっていますか？あなたがJavaであれば、スマートな列挙型を使用できますか？ （あなたは、C＃でこれらを模倣することができますが、できるだけ多くのサポートはありません。）

は、私は、これは、少なくともプロンプトが異なるデザインを考慮しなければならないと言うだろう - しかし、それはよくあなたが欲しいものを行う最も簡単な方法かもしれません。

Answer 4

いいえ、不作為が悪いのスタイルではありません。

Answer 5

コード臭は設計上の問題を意味します。これは単なるフォーマットの問題です。ほとんどの人は、休憩を省略したバージョンが優れていることに同意すると思います。

Answer 6

ブレークは冗長です。

いくつかの経験則では、常に1つの場所で機能を終了するのは良いことですが、このルールが作成されてからTry-Catchが発明されました（oop goto）。

アプリケーション全体で同じスタイルを維持している場合は、スイッチでリターンを生かすことができます。

Answer 7

私はコードはあなたがこの私のように本当にハードコーディングnumersならそうこれらの観察のいくつかは...

「ケース1」 適用できない場合がありますことを意図していることをどのようにリテラルわかりませんそれが貧弱なスタイルだと思って、あなたは列挙を使って調べるべきです。

単純に何かを返すだけで、ケースのサブセットに追加のロジックがない場合は、配列や辞書に "somethings"を入れ、switch文を使用するのではなくインデックスでアドレスするだけです。 ..

戻り代[インデックス]

Answer 8

ここでコードのにおいがcase文にハードコードされた値です。

返品については、味と判断の問題です。もちろん、あなたのケースが複数のページにまたがっている場合は、リターンがケースに入っていれば読むのが簡単ですが、問題は大きなスイッチで始まります。

Personnaly私は、これまで以上に処理を追加する必要がある場合は、すべてのケースを訪問するよりもリファクタリングが安価なので、単一戻りオプションを使用します。また、リファクタリングのために他の人に与えられた場合、彼らはすべての場合にコードを貼り付けるという誘惑を持っていないだろう、少なくとも私はそう望むだろう...彼らが彼らのコードレビューをしている人ではない明らかにコピーペースト）。

Answer 9

スイッチステートメント自体がコードの匂いです。

l99057jの行に沿って、入力を一定値にマッピングするだけであれば、これは適切な検索構造のための場所です。たとえば、順次入力の配列/リストスイッチ文ではなく、疎なものです。あなたが何かを計算しているならば、その値はあなたが入力で呼び出す代理人になります。

Answer 10

他は、他の側面についてコメントしています。戻り値の後で冗長なブレークについては、ボディーが単一のステートメントの周りに{}と同じ理由でそれらを保持します。すべてのプログラマーがそれらのブレークをそこに置くのは第二の性質でなければなりません。無意識に欠けているものよりも冗長な休憩が100回ある方がよい。