とある掲示板で「条件分岐は悪」という発言を見かけたのですが実際どうなんでしょうか？

Question

とある掲示板で「条件分岐は悪」という発言を見かけたのですが実際どうなんでしょうか？
またその理由も教えてください。

Answer 1

オブジェクト指向言語のポリモーフィズムの文脈では「条件分岐は悪」という考え方はありますよね。
送信側で条件分岐をして処理を変えるのではなく、受け手を抽象化してポリモーフィズムに従って実装すれば条件分岐がなくなります。

「なぜ悪なのか」という答えは、、、すみません、わかりません。複雑になるからですかね？

ちなみに、純粋オブジェクト指向言語と呼ばれている Smalltalk には他言語のような「if文」はありません。
http://ja.wikipedia.org/wiki/Smalltalk

Comments

[chokojori]

> 「なぜ悪なのか」という答えは、、、すみません、わかりません。複雑になるからですかね？

ポリモーフィズムの文脈では、たとえば新しいサブクラスを追加することで処理パターンを増やせるのに対し、条件分岐で型判定する実装ですと、型が増えたときにすでに書かれている条件分岐に手を入れなければなりません。既存部分がテストの対象になるかならないかという違いが生じますね。

[YUKI_0618]

関数は基本的に、行いたい処理を箇条書きにした程度のものが望ましいですよね
条件分岐は最小限にとどめ、関数が複雑になるようならいくつかの関数に分けると
ポリモーフィズムなら、基底クラスやインターフェイスに必要そうな関数をすべて用意しておけば、is判定などは一切必要なくなるでしょう

以前読んだ本に、1つの関数は100行以内にするということが書いてありました
曰く、関数名がコメント代わりになるほどがよいと
{
　　//○○の数を数える
　　int a = 0;
　　for(int i = 0....
　　　　if(△[i] == 〇〇) a++;

　　//全ての○○について処理
　　//...
}
↓
{
　　int a = count○○(list);
　　Process○○(list, a);
}

Answer 2

あくまで推測ですが、１つの関数で何でもかんでもやってしまおうとして、引数に条件判断用のパラメータだらけ、内部ではやたらネストの深い条件分岐、というような作りのことを言っているとすれば確かにスパゲッティ化してバグの温床になりますので「条件分岐は悪」と言われるでしょう。

まあ条件分岐が全くない、ということはありえないので程度の問題だとは思いますが、将来のメンテナンスのためにもあまり複雑怪奇な構造にしないというのはコーディングの基本だと思います。

Answer 3

前にもおっしゃられている通り前後の文脈が分からないのでなんとも言えませんが、
条件分岐は私は悪ではないと思っております。
なぜなら条件分岐は必ず出てくるものですから。
それを無理に処理したりするのは逆に可読性を落とす原因になるのではないかと。

私の中での悪の条件式というと例として1つif文を挙げさせて頂くとネストの多い条件式です。
つまり
if() { // if1
if() { // if2
if() { // if3
} else {
}
} else {
}
}else{
}
のようにifが続くものは私個人は悪だと思います。
この場合if3まで処理を追う場合にif1とif2の値を頭に覚えておく必要があるからです。
つまり、バグが発生した場合にデバッグを用意の行う事ができません。
このようなif文は経験上、ある程度は解消する事ができます。

リーダブルコード等の書籍を読んでみると悪のif文がどのようなものなのかは
わかりやすくのっています。
私のこの見解も本で学び実際にやってみたところかなりスッキリしたので紹介させて頂きました。

Answer 4

「条件分岐は悪」という部分だけを拾い出してしまうと、なかなか真意を読み取れないですね。
的を得ているかは解りませんが、思うところを書かせて頂きます。

「条件分岐は悪」という言葉が指しているところは、
手続き型プログラミングでは、if、switchをなどの条件分岐で処理を分けますが、
プログラミングでのバグの多くは条件分岐にあることが多いということに対して、
オブジェクト指向プログラミングでいえば、クラス・インスタンスを分けること、
関数型プログラミングでいえば、引数のパターンマッチを利用して分けることで、
条件分岐をしなくても処理を分け実行できるようにすれば、
バグが減るという考え方の話なのかと思います。

私個人としては、あまりそこにこだわる必要はないと思います。
プログラムはロジックだけでなく、可読性、メンテナンス性、性能やコストなど、
良い悪いというのも視点を変えれば変わります。
プログラミングにはいろいろな言語があり、流行りのようなものもがありまから、
今この考え方がいいとなっていても数年後は変わっていいることもあるでしょう。
一つの言葉に固執せず臨機応変に考えるべきかと思います。
しかし、臨機応変すぎると無秩序になるので、指針がとしては良いかもしれません。

論点がずれていたり質問の回答になってなかったらごめんなさい(^_^;)

Answer 5

文脈が分からない以上、意図も当て推量ということになりますが…。

機械語レベルでの処理パフォーマンスの話だとすれば、条件分岐でパイプラインが吹き飛ぶケースがあってボトルネックとされることがあります。

分岐ハザード

Answer 6

おそらくは、コンピュータの処理特性上コストが高いから出来るだけ減らせという意味合いだと思います。だとするならば該当するのはif文, switch文だけでなく、for文, while文も同じです。

コンピュータの性能が著しく向上したせいなのか、最近はあまりそういう話は聞かなくなりました。しかし今でも、大量のデータを扱う処理などでは、どうやったら少しでも速く処理させるかを考えることは必要だと思います。

Answer 7

条件分岐そのものに良し悪しは無いでしょう。
条件分岐を利用して実装した結果、条件分岐の短所、長所、役どころを使いこなせているかどうかではないでしょうか。
他回答に有るように、条件分岐を利用しなくても成り立つケースが有るのに、わざわざ条件分岐を使ったら、それは結果として実装者ではなく、条件分岐が「悪」として扱われがちです。
こういう事態に陥りやすい人は、たいがい設計時に使用する言語に囚われてしまっている人がおおいです。

Answer 8

条件分岐は確かに悪ですが、回避法としてよく用いられる state / strategy パターンは
どうしても 大がかりすぎて、やろうとしていることに対してコストが
かかりすぎることが多い。

場合分け爆発が起こる場合、状態遷移が必要な場合というのは、
たとえば、GUIで、同じボタンがモードごとに処理が違う場合、
より具体的には、[copy]ボタンは、選択されているものが文字か図形かで処理が違ったりする。
こういう場合は、明らかに state と strategy パターンを使うべき、ということになります。
やってみれば分かりますが、かなりすっきりする場合も多いです。

ただしこれは、条件分岐が山ほど増えてきて、かつそれぞれの処理ブロックでやることが
全く違う場合であって、ほぼ同じことをするだけの条件分岐ならば、switch文などで
処理した方が 後で見ても 圧倒的に楽だし、パフォーマンス上もよいのです。

パフォーマンス性能やらリーダビリティが優れている方を取るべきで、
条件分岐を回避すべきときとそうでない場合がある、というのが真の回答で、
こういう問題こそ、グループで相談して決めるべきことかと思います。

Answer 9

下手なロジックを組むなという事であって、状況次第だと思います。
Cで極端な例を出すと

分岐

if (a > 0)
	c += b;

cycle++;
if (cycle >= 16)
	cycle = 0;

分岐なし

c += b * (a > 0);

cycle++
cycle = cycle % 16;

一般には前者の書き方が良いとされていますね。
後者は言語機能に強い人にはすんなり把握できますが、人により一瞬？？？となる書き方でしょう。
個人的には分岐を使うかどうかはその処理の抽象度によります。処理が漸化式や法に基くなら分岐排除して良し、そうでなければ分岐で(ポリモーフィズムの場合も抽象度で判断)。

「悪」の発言者は、誰かから「テストで分岐のカバレッジを100%にしろ」と言われてうんざりしているとか？前者で書いてもコンパイラが後者のロジックを吐いたりしますし。

Comments

[退会済みユーザー]

失礼ながら、
cycle %= 16;
では、cycleが17以上の場合上のプログラムと同値にならない気がするのですが……
書くのであれば、
cycle = cycle * (cycle < 16);
になるかと思います。

[rubato6809]

なるほど、一般論というか、if文だけを見れば同値ではないけど、直前に cycle++; があるので、これはこれで良いのです。変数名"cycle"が示すように、値を
　０→１→・・・１５→0→１　と循環させたいことは良くあることで、常套句のようなものだからです。
さらに、１６のような２のべき乗で余りを求める場合はAND演算が使えます。即ち
　cycle = (cycle + 1) & 15;
最適化コンパイラがこのようなコードを生成することもあります。

Answer 10

ある人はgotoを使うなと言います。ある人はネストの深いところから抜けるのにgotoを使うと言います。「ネストの深いところ」がないほうがいいのに決まっています。ただ、例外処理が実装されてない言語もあるので一概にgotoダメとは言えないところもあります。(関数の途中からreturnで戻るのも広義のgotoと変わらない)なので、私はネストが深くなりそうだったら、関数としてほおり出せばいいと思っています。・・・けっこう使いますね途中からの脱出＾＾；
#・・・２千行もあるＣの関数見せられたら作った奴を呪いたくなります；；
すみません長々とｍｍ

Answer 11

よろしければ、その掲示板のURLをご教示いただけないでしょうか。
前後の文脈が分からないと何とも言えないです。。。