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

booleanを返すケースで冗長なif文が作られるのは何故かというのをツイートしてみたら、多くの反響があったのでまとめてみました。
43
前へ 1 ・・ 3 4 6 次へ
あらやおーいぇ🇺🇦 @ArayaOhyeah

これって最適化されるのかな twitter.com/kmizu/status/1…

2021-06-17 01:32:42
kmizu @kmizu

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

2021-06-17 00:13:47
社畜戦士⭐︎パツラ @feroce1022

@kaname bool isEnabled = false; try { ///判定文  if〜 isEnabled = true; } cathe(Exception e) { ///エラー処理 } return isEnabled; 的な感じで僕は組んでました😅 クソリプすいません🙇‍♂️

2021-06-17 01:35:24
Kaname Funakoshi @kaname

@feroce1022 isEnabledの意味が関数の意味と同じ(返す関数値としてisEnabledを利用する前提)で処理を進めるならそれがエレガントですよね

2021-06-17 01:35:31
#FFC6D6 @amukater

func showEnableMark() -> Bool みたいな関数の中身だったら気持ちは分からなくもない。isEnableとshowは意味が違うから、この場合はこう、この場合はこう、みたいにボーッとしてる時は書いちゃいそう twitter.com/kmizu/status/1…

2021-06-17 01:36:57
葦月暮葉 @c6h18nnasi2

isEnabled云々はぶっちゃけどうでもいい派ですね...そのまま返したほうが多少は効率よさそうぐらい。むしろこんなのにぐたぐた言い続ける人とは一緒に仕事したくねーって気持ちのほうが😑

2021-06-17 01:37:29
a_sir @a_sir

@kmizu 変数がスイッチのON/OFFで、関数がスイッチの状態を問うものだったらreturn 変数って書くけど、スイッチで点灯するライトの状態を問うものだったら変数とはたまたま値が一致するだけで違うものだから明示的にロジックを介すと思います。暗黙の前提条件があるコードは未来のバグの元なので

2021-06-17 01:42:45
a_sir @a_sir

@kmizu ポインタとか参照をreturnして内部状態を暴露してしまった経験のある人が、必要以上に警戒しているケースもあるかもしれないです

2021-06-17 01:44:24
まじかんと @tnacigam

If-else 文の中の return 文にブレイクポイントを設定することで片方の条件の時だけブレイクできるといふバッドノウハウなら知ってる (え、おたくのデバッガーは条件付きブレイクポイントをサポートしてないの?) twitter.com/kmizu/status/1…

2021-06-17 01:44:59
ともの(P💉💉+M💉💉💉💉) @TomonoTokyo

ドキュメントと合わせる、それぞれの行にコメントを記述する、という目的とかだったらあるかも。インタフェースはバグが多く生まれるところなので。 どうせ最適化/論理圧縮で冗長な部分や性能面の問題はなくなるだろうし。 twitter.com/kmizu/status/1…

2021-06-17 01:57:10
鯉江 @koie

@kmizu 関数名が get_isEnabledならそのままreturnて書くけど、最初はif使って書いちゃうかな。その後気づいて直すかも。条件が入り組んでるときは if (isEnabled) return true; return false; と書くかもしれない。

2021-06-17 02:01:12
こたうち さんさん @kotauchisunsun

twitter.com/kenchacha/stat… twitter.com/kmizu/status/1…

2021-06-17 02:20:07
みながわけんじ @kenchacha

「実はオブジェクト指向ってしっくりこないんです」から10年 ⇒ ameblo.jp/kenchaz/entry-… #アメブロ @ameba_officialさんから

2020-05-26 12:51:49
kmizu @kmizu

今更なんだけど、今日ちと盛り上がった「staticおじさん」 el.jibun.atmarkit.co.jp/minagawa/2010/… と関連して、ちょっと古いけど "staticおじさんの逆襲" について、結論をまとめておく。 qiita.com/minebreaker/it… この両方ともに、議論の方法自体に根本的な問題があるというのが結論。 ↓

2021-06-16 23:17:13
鯉江 @koie

isEnabledが実は enum { DISABLED, ENABLED,INPROGRESS } で確定するまで待ち合わせがあるかもしれんな。

2021-06-17 02:33:37
川下盆蔵 @yamaborn

ログ出力デバッグした後ログ出力だけ取っ払って、コード整理する過程でのエンバグを怖れてそのまま放置、最適化でなくなるから遅くはならないよね、という感じ? か、true返す時とfalse返す時の両方をのケース通ったことをカバレッジから確認できるようにするための運用とか? twitter.com/kmizu/status/1…

2021-06-17 02:47:27
Kawakami @kawakami_o3

@koie @kmizu しっ!あらたな論争を読んでしまいますよ get_isEnabled

2021-06-17 05:01:53
ホワイト/SIV @White_Zoroark

言語によってはisEnabledのスコープとかいつまで有効かが重要かも知れない スレッドにもあったけど可読性やブレークポイント挿入時を考えてというのもある バグ発生時にisEnabled返してたら、ifでtrue/falseに書き換えるのは動作変わる可能性あるので嫌がる(それでも冗長なので普通はisEnabled返す)

2021-06-17 05:30:19
ねこへい @cyberCatvb

@kmizu @melponn 横から失礼します。 VisualStudioならreturn isEnabledに修正提案してくれそう。

2021-06-17 06:00:29
のぼっこ🔂 @nobokko

ぶっちゃけこれだけの情報だと良いとも悪いとも言いづらいんだよね。 型そのものより意味を重視するからそこにズレがあるならこの書き方にしてもらう場合もある。 あと、カバレッジで各々のパターンを通ったことを確認するのはなるほどと思った。 いずれにしても三項演算子よりはまだありえる書き方。 twitter.com/kmizu/status/1…

2021-06-17 06:18:06
𝘺𝘢𝘣𝘦_𝘻 @moto_musyoku2

@kmizu 全体的な雰囲気から、将来何かの終了処理を追加しなければならない予感がするときはそう書くことがあるかも。

2021-06-17 06:21:51
まろ@関数型言語作曲機械学習勉強してない @_marony

いや、深く考えすぎ 何かの時何かを返すと指示された/考えたからそのまま実装しただけ 深い意味なんてない ↓ ↓ ↓ if(isEnabled) { return true; } else { return false; }

2021-06-17 06:35:34
👻 道化師 🃏 @wraith13

バグベアードみたいなの使ってると return の値のログは残らなくても if の分岐のログは残せたり、カバレッジ測定的にもこの方が望ましかったり、デバッグ時にブレイクポイントを仕掛けやすい、ログを埋め込む際にも埋め込みやすい、"return true;" で検索できるなど、いくらでも利点がある。 twitter.com/kmizu/status/1…

2021-06-17 06:35:58
結城浩 / Hiroshi Yuki @hyuki

@gakuzzzz @kmizu たとえば「第325回 スタックとキュー(前編)」のM18-M22の部分のことですね。M18で return IS-EMPTY(S) と書いてももちろん同じことですが、テトラちゃんの意図は「この手続きを見ただけで必ずtrueとfalseのどちらかが返ることが明確である」だと思います。(続く) link.hyuki.net/girlnote325 pic.twitter.com/EV8LlFrhVZ

2021-06-17 06:43:12
拡大
結城浩 / Hiroshi Yuki @hyuki

@gakuzzzz @kmizu return IS-EMPTY(S) と書くと、この手続きMATCHEDの戻り値が確かにtrueまたはfalseであるかは、IS-EMPTYの戻り値に依存することになります。「ifの中では真/偽と判定できるけれど、実際の値はtrue/falseではない」という言語は珍しくありませんから、MATCHEDの仕様が「trueまたはfalseを返す」の場合、

2021-06-17 06:46:12
結城浩 / Hiroshi Yuki @hyuki

@gakuzzzz @kmizu return IS-EMPTY(S) と書くのが妥当かどうかは、言語仕様にも依存することになります。このWeb連載では使っている擬似言語の詳細や慣用句などは何も説明していませんので、説明や他の手続きへ依存することなくMATCHEDが確かにtrue/falseを返すことを確信するためには、明示的にtrue/falseを書くことを

2021-06-17 06:49:02
結城浩 / Hiroshi Yuki @hyuki

@gakuzzzz @kmizu 選ぶのがいいと思います。繰り返しますが、return IS-EMPTY(S)と書いてもこの場合はもちろん正しいです。プログラミング言語に馴れている人ならば、こちらの方が短くて明確だと感じると思います。私も、特定のプログラミング言語の文章ならば、そのように書くと思います。

2021-06-17 06:51:47
結城浩 / Hiroshi Yuki @hyuki

@gakuzzzz @kmizu 以上です。ていねいにお読みくださりありがとうございます😊

2021-06-17 06:52:25
前へ 1 ・・ 3 4 6 次へ