switch
一連のif
ステートメントに対してブロックを使用する理由は何ですか?
switch
ステートメントは同じことをしているように見えますが、入力に時間がかかります。
switch
一連のif
ステートメントに対してブロックを使用する理由は何ですか?
switch
ステートメントは同じことをしているように見えますが、入力に時間がかかります。
ほとんどのものと同様に、コンテキストに基づいてどちらを使用するかを選択し、概念的に正しい方法を選択する必要があります。スイッチは実際には「この変数の値に基づいてこれらのいずれかを選択する」と言っていますが、if ステートメントは単なる一連のブール チェックです。
例として、次のことを行っていたとします。
int value = // some value
if (value == 1) {
doThis();
} else if (value == 2) {
doThat();
} else {
doTheOther();
}
これは、任意のテストではなく、「値」の値に基づいてアクションの選択が行われていることがすぐに明らかになるため、スイッチとして表す方がはるかに適切です。
また、スイッチや if-else を作成し、OO 言語を使用していることに気付いた場合は、可能であればそれらを取り除き、ポリモーフィズムを使用して同じ結果を達成することを検討する必要があります。
最後に、switch のタイピングに時間がかかることについて、誰が言ったかは思い出せませんが、「あなたのタイピング速度は、コーディングの速さに影響を与えるものですか?」という質問を読んだことがあります。(言い換え)
単一の変数の値をオンにする場合は、毎回スイッチを使用します。これが、構成が作成された目的です。
それ以外の場合は、複数の if-else ステートメントを使用してください。
私は通常、switch ステートメントよりも if/else 構造を好みます。特にフォールスルー ケースを許可する言語ではそうです。多くの場合、プロジェクトが古くなり、複数の開発者が関与するようになると、switch ステートメントの作成で問題が発生するようになります。
それら (ステートメント) が単純以上のものになると、多くのプログラマーは怠け者になり、ステートメント全体を読んで理解する代わりに、ステートメントに追加するケースをカバーするために単にケースをポップします。
人のテストがすでにカバーされているため、switch ステートメントでコードが繰り返される多くのケースを見てきました。単純な失敗のケースで十分だったでしょうが、怠惰により、switch を理解しようとする代わりに、最後に冗長なコードを追加することを余儀なくされました。 . また、構築が不十分な多くのケースを含む悪夢のような switch ステートメントもいくつか見てきました。単純にすべてのロジックに従おうとすると、多くのフォールスルー ケースが全体に分散し、そうでない多くのケースが困難になります ... of は、私が話した最初の/冗長性の問題につながります。
理論的には、if/else コンストラクトにも同じ問題が存在する可能性がありますが、実際には、これはそれほど頻繁には発生しないようです。おそらく (単なる推測ですが) プログラマーは、if/else 構造内でテストされるより複雑な条件を理解する必要があるため、もう少し注意深く読む必要がありますか? 他の人が決して触れないだろうとわかっている単純なものを書いていて、それをうまく構築できるなら、それはトスアップだと思います。その場合、そのコードを維持する可能性が高いため、より読みやすく、あなたにとって最も良いと感じるものは、おそらく正しい答えです。
多くの場合、switch ステートメントは if-else コンストラクトよりも高速に実行されます (常にではありません)。switch ステートメントの可能な値は事前に配置されているため、コンパイラはジャンプ テーブルを構築することでパフォーマンスを最適化できます。各条件は、if/else コンストラクトのようにテストする必要はありません (とにかく、適切な条件が見つかるまで)。
ただし、常にそうであるとは限りません。たとえば、可能な値が 1 ~ 10 の単純なスイッチがある場合、これが当てはまります。追加する値が多いほど、ジャンプ テーブルを大きくする必要があり、スイッチの効率が低下します (if/else よりも効率が悪くなりますが、比較的単純な switch ステートメントよりも効率が低下します)。また、値が非常に多様な場合 (つまり、1 から 10 の代わりに、1、1000、10000、100000、100000000000 などの 10 の可能な値がある場合)、切り替えは単純な場合よりも効率的ではありません。 .
お役に立てれば。
1 つの変数に 2 つ以上の条件がある場合は常にスイッチを使用します。たとえば、平日を例にとると、平日ごとに異なるアクションがある場合は、スイッチを使用する必要があります。
その他の状況 (複数の変数または複雑な if 句の場合は If を使用する必要がありますが、それぞれをどこで使用するかについての規則はありません。
タイプするのに時間がかかるという理由で何かを避ける傾向は悪いことです。根絶するようにしてください。とは言っても、冗長すぎると読みづらいので、小さくてシンプルであることが重要ですが、重要なのは書きやすさではなく、読みやすさです。簡潔なワンライナーは、よくレイアウトされた単純な 3 行または 4 行よりも読みにくいことがよくあります。
操作のロジックを最もよく説明する構成を使用してください。
個人的には、入れ子になった if-else よりも switch ステートメントの方が読みやすいので気に入っています。スイッチは、状態を表示するための読みやすさの点でも優れています。
pacman ifsに関するこの投稿のコメントも参照してください。
これは、特定のケースに大きく依存します。できれば、ネストされた が多数switch
ある場合は、 を使用する必要があると思います。if-else
if-elses
問題は、いくつですか?
昨日、私は自分自身に同じ質問をしていました:
public enum ProgramType {
NEW, OLD
}
if (progType == OLD) {
// ...
} else if (progType == NEW) {
// ...
}
if (progType == OLD) {
// ...
} else {
// ...
}
switch (progType) {
case OLD:
// ...
break;
case NEW:
// ...
break;
default:
break;
}
この場合、1if
番目には不要な 2 番目のテストがあります。2ndはNEWを隠してしまうので少し気持ち悪いです。
switch
より読みやすいという理由で、最終的に を選択しました。
異なる値を持つ可能性のある単一の変数でのみ作業しているため、switch を使用することに決めたとしましょう。これが小さな switch ステートメント (2 ~ 3 ケース) になる場合は、それで問題ないと思います。より多くの結果が得られると思われる場合は、代わりにポリモーフィズムを使用することをお勧めします。ここで AbstractFactory パターンを使用して、スイッチで実行しようとしていたアクションを実行するオブジェクトを作成できます。見苦しい switch ステートメントは抽象化され、よりクリーンなコードになります。
私はしばしば、elseif を使用してケース インスタンスをドロップすること (言語が許可する場合) は、コードの匂いではないにしても、コードの匂いだと考えてきました。
私自身は通常、ネストされた (if/then/else) は通常、elseif よりも物事をよく反映し、相互に排他的な場合 (多くの場合、属性の 1 つの組み合わせが別の組み合わせよりも優先される場合) では、case または類似のものの方が明確であることがわかりました。 2年後に読む。
Rexx で使用されるselectステートメントは、"Case" を適切に行う方法 (ドロップスルーなし) の特に良い例だと思います (ばかげた例):
Select
When (Vehicle ¬= "Car") Then
Name = "Red Bus"
When (Colour == "Red") Then
Name = "Ferrari"
Otherwise
Name = "Plain old other car"
End
ああ、最適化がうまくいかない場合は、新しいコンパイラまたは言語を入手してください...
Switch ステートメントは、読みやすく維持しやすいことは言うまでもありません。また、通常は高速でエラーが発生しにくいです。