編集可能
2021年6月17日

冗長なif文が作られる理由諸説

booleanを返すケースで冗長なif文が作られるのは何故かというのをツイートしてみたら、多くの反響があったのでまとめてみました。
38
ゆうすけ@iOSアプリ開発 @U_su_K

SwiftUI ButtonStyleでisEnabledの取得について調べました。 zenn.dev/usk2000/articl… #SwiftUI

2021-06-09 10:47:36
Kota Mizushima (on a diet) @kmizu

関係ない話題。初学者のみならず、仕事でコード書いてる人でも、 if(isEnabled) { return true; } else { return else; } と書いちゃう人と時々遭遇するのだけど、これはなんでなんだろう。 ↓

2021-06-17 00:13:47
Kota Mizushima (on a diet) @kmizu

true/falseの二値を返すということは、当該関数がbooleanを返り値としてを期待しているというのは理解している……と思えるのだけど、しかし、理解していれば、 return isEnabled; になるはず。 ↓

2021-06-17 00:13:47
Kota Mizushima (on a diet) @kmizu

一つありえる仮説としては、そういう人はreturnには即値しか書けないと思い込んでるとか?しかし、そういう人でもreturn 変数名;とかは書いてたりするんだよなあ。 boolean型の変数だけが何か特別であると思いこんでいる?この種のコードに時々遭遇する理由がわからない(初学者の場合はわかる)。

2021-06-17 00:13:47
dif_engine @dif_engine

@kmizu printf デバッグの名残で(結果として)こうなってしまった記憶があります.

2021-06-17 00:16:20
take2 @take2webservice

@kmizu boolean型の変数が(条件分岐などで使えて)特別であると思い込んでるに1表! それが手癖になって抜けない人がちょいちょいいる感じでしょうかー (僕自身そんな感じだった気がします)

2021-06-17 00:17:33
Takashi Kawasaki @espresso3389

とはいえ、こういうのはIDEの支援機能で潰していくべきだな。 twitter.com/kmizu/status/1…

2021-06-17 00:20:43
がくぞ @gakuzzzz

@kmizu 日本語ドキュメント直訳論を提出しておきます twitter.com/gakuzzzz/statu…

2021-06-17 00:21:04
生存中のoxy @oxycaster

@kmizu 僕も昔書きがちでしたが、isEnabledの時とそうでない時の処理を挟むつもりで書き出してとりあえず書きはじめたけど、周辺を整理したらそこでは必要なくなり…みたいな時に消すのを億劫がってそのままにしちゃったりは…w

2021-06-17 00:21:08
hrsh7th @hrsh7th

@kmizu 脳内の日本語を書き下してるのだと思います。(自分も気持ちはわからんでもないです。) 「〜が有効なら true を返す」という文がコードになったものです。

2021-06-17 00:21:30
星の海のビビ(Vivi) @strategic_vivi

@gakuzzzz @kmizu 僕もこれだと思います(;´∀`) 日本語直訳論

2021-06-17 00:22:47
市川 真一 @tenpoku1000

@kmizu C で bool 型を返す関数を書いていると、関数の返り値を変数に保存しないケースが頻出することがあるので、以下のように書いています。変数に保存して分岐などする場合は、変数を返すようにしています: if ( ! function_B()){ return false; } return true;

2021-06-17 00:23:53
KOIZUKA, Akihiko @koizuka

@dif_engine @kmizu ああ、片方の値の時にデバッガのブレークポイントを設置する目的でもそういうことやった時代はあるな〜(値条件ブレークがないような時代)

2021-06-17 00:24:31
がくぞ @gakuzzzz

これ数学ガールの最近の連載でもこう書かれてるんですよね。結城先生の事だから意図的にそちらの方がわかりやすいという判断をされたんだろうなーと思いつつ、なぜその方がわかりやすいと判断されたのかはまだ自分の中で解を見出だせてない twitter.com/kmizu/status/1…

2021-06-17 00:24:44
最後のだるやなぎ族 @daruyanagi

最近の IDE なら直してくれるよなって思ったけど、そもそも IDE 使わないか twitter.com/kmizu/status/1…

2021-06-17 00:27:50
アズなんとかさん @as_capabl

@kmizu if(isEnabled) と書ける人も実は思ったほど多くなくて、「ifの中には条件演算子がないとダメ」という認識がはびこっている可能性がが

2021-06-17 00:31:20
$LQFC ☀️ @0xlqfc

@kmizu レビューされて気づいたことが過去に数回あります 理由はreturn isEnabledで成立するコードって滅多に遭遇せず不慣れだったからです 前者のif elseのパターンの方が頻出フレーズなので無意識レベルで書きあげていました

2021-06-17 00:32:54
すとまと @stmtk_yu

JSでisEnableが真偽値じゃないけど、返り値は真偽値にしたい的な? !!isEnableって書けば済む話だけど twitter.com/kmizu/status/1…

2021-06-17 00:34:12
Takeshi YAMAZAKI (Takep) @tymzk7

レビューでこれ出てきて直させた側の人間だけど、「設計書の決定表とコードを見比べた時にこの方が分かりやすいと思ったのでこうしました」と言われた記憶(どういう意図かはちょっとよく分からなかった) twitter.com/kmizu/status/1…

2021-06-17 00:35:56
azu @azu_re

return isEnabledは使ってるエディタと相関ありそう

2021-06-17 00:36:56
sarubo @sarubo2016

isEnabled(何の値が入るかわからない。とりあえず値があるか確認)

2021-06-17 00:39:18
y2_naranja@🦀ナランハ🍊 @y2_naranja

else のところ、return false; だよね……? そうでなかったら破壊的にどうしようもない twitter.com/kmizu/status/1…

2021-06-17 00:40:17
kenichiuda @kenichiuda

ここまでのは無いが、 bool isDisabled() { if(isEnabled == false) return true; else return false; } は稀によく見る。 インタビューしたわけではないが、恐らく頭の中では「isEnabledの逆」とは考えず「isEnabledが偽なら真、それ以外なら偽」と考えている。 twitter.com/kmizu/status/1…

2021-06-17 00:40:29
残りを読む(111)

コメント

Earwax @Earwax97409510 2021年6月17日
可読性について考えると、if版は7組のオペコードとオペランドを漏れなく正しく読み込んだ上でそれら全文を間違い無く脳内コンパイルするまで実際の挙動を再現出来ず、return isEnabled版に対して人為的ミスが入り込む余地が多すぎる。内部の文脈上意味が違うのを表現できるという点は尤もだが、品質を犠牲にしてまで求める事ではないな。
2
rambda(仮) @rambda_kari 2021年6月17日
Earwax97409510 実際、例文でreturn elseというミスをおかしているしな。
4
たかつき @taka4tsuki 2021年6月17日
ワイは文脈上の意味の違いの表明は保持すべき派だなあ程度によるけど。その外側の判定関数の戻り値が、他の何かの isEnabled と一致しているのはたまたま偶然であり、それが実は間違いだったり、後々で変更されたりもあり得るし、あとコードを読む他の人に「これは意味的には別次元の判定なのだ」とメッセージを残す意図もある。ただし最初の例文のレベルであそこまで単純なら素直に isEnabled を返してもよい気もする。
8
えめどん @emedon 2021年6月17日
これとは別で、私は若手へのレビューの際には条件分に否定を使うなと言ってる。 「●●以外」を厳密に検証するには大変な場合があり、それを見落として思いもよらぬエラーになる可能性があるから。
1
yuki🌾㊗️6さい🎉⚔ @yuki_obana 2021年6月17日
isEnabledってダイレクトにboolean返せないの?そのままじゃなくても単純な判定式にモディファイできないのん?return以外のプロシージャもないならif自体要らなくない?????(´・ω・`)いまいち意図がよくわかんない
0
system.exit() @192_168_0_100 2021年6月17日
まとめの中に最適化されるのかといったつぶやきがあったので、Javaで確認してみましたがコンパイラはちゃんとreturn isEnabled;にするみたいですね。
4
ARENA @Arenacyan 2021年6月17日
ソースコードの行数で評価される制度なので、分かってて無意味に行数を増やす手段として使ってる可能性微レ存?
0
Fumito Mizuno 📕 #のベルズ @ounziw 2021年6月18日
処理の流れに依存する気がする。 (A)パターン このコードの前にisEnabledをtrue/falseに設定する処理がある場合。 → この場合はif文は明らかに冗長だと思う (B)パターン isEnabledの値はどちらもあり得る&isEnabledの値によって処理を変えることを示したい場合。 → if文書いてもおかしくないと思う。
1
wbPQMyU @wbPQMyU1 2021年6月18日
Cなんかの数値型をif文に入れてた名残説。これは数値ではなくBoolだと強調するためでは。
1
ナス大好きおじさん@ナレッジワーカー @nasudaisuki_oji 2021年6月18日
昔の大規模システム開発とかでコードレビューとかやってて熟練者からアーダコーダ言われてたので、可読性とかステップ数減らしたりとか、なんなら見た目カッコよく・・・!みたいな世代ですが、現在の安価短納期世代で働く人たちには仕事で教えてもらえる機会もないだろうし、独学するほどの気力もないだろうし、ちょっとかわいそうな気もする今日このごろ。あれ、分岐の中にreturn入れたらIDEに怒られませんでしたっけ?٩( ᐖ )۶
0
雲雀っちゃ @anas1yam 2021年6月18日
不正値がisEnableに入った場合の対策だろうなあ (同じ観点でif文の条件式もisEnable == trueにするべきだと思う)
0
くにたちの幼生 @uJuypjYCMaxFNIz 2021年6月19日
返り値でboolが指定できない(そんなことあんのか?)とか、PHPのように動的型付け言語で bool 以外のものが if() で 通ってしまう場合(PHPはすごいよね)は分かる。というかやれ、と思う。が、JavaとかC#とかでやられたら無駄なことしてんなーと思うな。
0
ゴロニャーゴ @nukopoint 2021年6月19日
isEnabledが間違いなくBoolean(静的型付けでかつ値がtrueとfalseしかない)だったら、isEnabled == true とか書くのは気持ち悪さしかない。何らかの宗教か、守ることで職場への忠誠を示すためだけのコーディングルールか、単なる無能のどれか。
0
ゴロニャーゴ @nukopoint 2021年6月19日
PHPで変な値が入っている可能性があるならtrueやfalseとは==ではなく===で比較するしなあ。
0
um @nanasi0003 2021年6月19日
最初の形を書いてるんだから○○は理解してるはず…って前提が間違ってて、どっかのコードのコピペで習得したぼくみたいな人は「こんな感じで書いたら動く」ってやってるだけ
0
こばた ふたる @Kass_kobataku 2021年6月19日
素人ながらの疑問だが、戻り値がisEnableのbool値に完全に依存したbool値であるときに、(ある程度抽象化した場合に限るのかもしれないが)戻り値とisEnable値が異なる(もしくは独立した)文脈(ないし概念)となることはあり得るのだろうか。
0
結城あすか @pixytale 2021年6月19日
古いC言語にはboolean型は存在せず、論理式の値も規格としては実装系依存(現実にはTRUE==1、FALSE==0の実装が多数だったろうけど)だったので、論理結果をそのまま返り値に返すことは関数仕様的にリスクがあった。よって論理値をif文で判定した後に(明示的に定義した)trueまたはfalseの値を返すことは考えられる。
0
たかつき @taka4tsuki 2021年6月19日
Kass_kobataku あり得る。例えばあるシステムが「食事を取るか」という判定を出すために「今は空腹か」と言う判定を使っていたとする。その時点でそのシステムが空腹なら即座に食事を取る仕様だとしても、本来これら2つの判定は別々の事象だし、であれば一体物して表現するべきではないし、後々に「目の前に食べ物があるか」という判定が追加されるかもしれない。
0
たかつき @taka4tsuki 2021年6月19日
taka4tsuki ただ、もちろん実用上はコードがスッキリしていた方が都合が良い場合が圧倒的に多いので、結局スッキリ寄りのケースバイケース。別々の判定関数を切ってあるだけ十分足りるという見方もできる。
0