これって最適化されるのかな twitter.com/kmizu/status/1…
2021-06-17 01:32:42関係ない話題。初学者のみならず、仕事でコード書いてる人でも、 if(isEnabled) { return true; } else { return else; } と書いちゃう人と時々遭遇するのだけど、これはなんでなんだろう。 ↓
2021-06-17 00:13:47@kaname bool isEnabled = false; try { ///判定文 if〜 isEnabled = true; } cathe(Exception e) { ///エラー処理 } return isEnabled; 的な感じで僕は組んでました😅 クソリプすいません🙇♂️
2021-06-17 01:35:24@feroce1022 isEnabledの意味が関数の意味と同じ(返す関数値としてisEnabledを利用する前提)で処理を進めるならそれがエレガントですよね
2021-06-17 01:35:31func showEnableMark() -> Bool みたいな関数の中身だったら気持ちは分からなくもない。isEnableとshowは意味が違うから、この場合はこう、この場合はこう、みたいにボーッとしてる時は書いちゃいそう twitter.com/kmizu/status/1…
2021-06-17 01:36:57isEnabled云々はぶっちゃけどうでもいい派ですね...そのまま返したほうが多少は効率よさそうぐらい。むしろこんなのにぐたぐた言い続ける人とは一緒に仕事したくねーって気持ちのほうが😑
2021-06-17 01:37:29@kmizu 変数がスイッチのON/OFFで、関数がスイッチの状態を問うものだったらreturn 変数って書くけど、スイッチで点灯するライトの状態を問うものだったら変数とはたまたま値が一致するだけで違うものだから明示的にロジックを介すと思います。暗黙の前提条件があるコードは未来のバグの元なので
2021-06-17 01:42:45@kmizu ポインタとか参照をreturnして内部状態を暴露してしまった経験のある人が、必要以上に警戒しているケースもあるかもしれないです
2021-06-17 01:44:24If-else 文の中の return 文にブレイクポイントを設定することで片方の条件の時だけブレイクできるといふバッドノウハウなら知ってる (え、おたくのデバッガーは条件付きブレイクポイントをサポートしてないの?) twitter.com/kmizu/status/1…
2021-06-17 01:44:59ドキュメントと合わせる、それぞれの行にコメントを記述する、という目的とかだったらあるかも。インタフェースはバグが多く生まれるところなので。 どうせ最適化/論理圧縮で冗長な部分や性能面の問題はなくなるだろうし。 twitter.com/kmizu/status/1…
2021-06-17 01:57:10@kmizu 関数名が get_isEnabledならそのままreturnて書くけど、最初はif使って書いちゃうかな。その後気づいて直すかも。条件が入り組んでるときは if (isEnabled) return true; return false; と書くかもしれない。
2021-06-17 02:01:12twitter.com/kenchacha/stat… twitter.com/kmizu/status/1…
2021-06-17 02:20:07「実はオブジェクト指向ってしっくりこないんです」から10年 ⇒ ameblo.jp/kenchaz/entry-… #アメブロ @ameba_officialさんから
2020-05-26 12:51:49今更なんだけど、今日ちと盛り上がった「staticおじさん」 el.jibun.atmarkit.co.jp/minagawa/2010/… と関連して、ちょっと古いけど "staticおじさんの逆襲" について、結論をまとめておく。 qiita.com/minebreaker/it… この両方ともに、議論の方法自体に根本的な問題があるというのが結論。 ↓
2021-06-16 23:17:13isEnabledが実は enum { DISABLED, ENABLED,INPROGRESS } で確定するまで待ち合わせがあるかもしれんな。
2021-06-17 02:33:37ログ出力デバッグした後ログ出力だけ取っ払って、コード整理する過程でのエンバグを怖れてそのまま放置、最適化でなくなるから遅くはならないよね、という感じ? か、true返す時とfalse返す時の両方をのケース通ったことをカバレッジから確認できるようにするための運用とか? twitter.com/kmizu/status/1…
2021-06-17 02:47:27言語によってはisEnabledのスコープとかいつまで有効かが重要かも知れない スレッドにもあったけど可読性やブレークポイント挿入時を考えてというのもある バグ発生時にisEnabled返してたら、ifでtrue/falseに書き換えるのは動作変わる可能性あるので嫌がる(それでも冗長なので普通はisEnabled返す)
2021-06-17 05:30:19@kmizu @melponn 横から失礼します。 VisualStudioならreturn isEnabledに修正提案してくれそう。
2021-06-17 06:00:29ぶっちゃけこれだけの情報だと良いとも悪いとも言いづらいんだよね。 型そのものより意味を重視するからそこにズレがあるならこの書き方にしてもらう場合もある。 あと、カバレッジで各々のパターンを通ったことを確認するのはなるほどと思った。 いずれにしても三項演算子よりはまだありえる書き方。 twitter.com/kmizu/status/1…
2021-06-17 06:18:06@kmizu 全体的な雰囲気から、将来何かの終了処理を追加しなければならない予感がするときはそう書くことがあるかも。
2021-06-17 06:21:51いや、深く考えすぎ 何かの時何かを返すと指示された/考えたからそのまま実装しただけ 深い意味なんてない ↓ ↓ ↓ if(isEnabled) { return true; } else { return false; }
2021-06-17 06:35:34バグベアードみたいなの使ってると return の値のログは残らなくても if の分岐のログは残せたり、カバレッジ測定的にもこの方が望ましかったり、デバッグ時にブレイクポイントを仕掛けやすい、ログを埋め込む際にも埋め込みやすい、"return true;" で検索できるなど、いくらでも利点がある。 twitter.com/kmizu/status/1…
2021-06-17 06:35:58@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@gakuzzzz @kmizu return IS-EMPTY(S) と書くと、この手続きMATCHEDの戻り値が確かにtrueまたはfalseであるかは、IS-EMPTYの戻り値に依存することになります。「ifの中では真/偽と判定できるけれど、実際の値はtrue/falseではない」という言語は珍しくありませんから、MATCHEDの仕様が「trueまたはfalseを返す」の場合、
2021-06-17 06:46:12@gakuzzzz @kmizu return IS-EMPTY(S) と書くのが妥当かどうかは、言語仕様にも依存することになります。このWeb連載では使っている擬似言語の詳細や慣用句などは何も説明していませんので、説明や他の手続きへ依存することなくMATCHEDが確かにtrue/falseを返すことを確信するためには、明示的にtrue/falseを書くことを
2021-06-17 06:49:02@gakuzzzz @kmizu 選ぶのがいいと思います。繰り返しますが、return IS-EMPTY(S)と書いてもこの場合はもちろん正しいです。プログラミング言語に馴れている人ならば、こちらの方が短くて明確だと感じると思います。私も、特定のプログラミング言語の文章ならば、そのように書くと思います。
2021-06-17 06:51:47