map / filter などの高階関数よりも古典的な for文の方が読みやすいと感じるあなたへ

class: center, middle # map / filter などの<br>高階関数よりも<br>古典的な for文の方が<br>読みやすいと感じる<br>あなたへ BuriKaigi 2025 2025/02/01<br> @gakuzzzz --- class: left, top ## 自己紹介 * 中村 学/Manabu NAKAMURA * Twitter: [@gakuzzzz](https://twitter.com/gakuzzzz) * [Tech to Value Co.,Ltd.](https://www.t2v.jp/) CEO * [Alp, Inc.](https://thealp.co.jp/) Tech Lead --- class: left, top ## はじめに 昨今のメジャーなプログラミング言語では、 `map` や `filter`

[hogeaegxa]

全件処理するなら何も考えずこのへんを使ったほうがいいと思うが、性能やらなんやらの理由で途中でbreakする分岐がある処理では、ギミックで頑張るとかせず普通にforで回したほうが奇麗なコードになると思う

[monorod]

forだとかmapだとかの前にまず三項演算子をネストして書いてるのをやめてほしいと思ってしまった。早期リターンとか使って判定処理を関数に切り出してよおねがい

[delphinus35]

「読み辛い」みたいな、linterで弾けないようなあやふやな理由ではレビューで指摘しないようにしている。明確に性能差が出るのでなければfor / ifだろうがmap / filterだろうが好みの問題です。

[Windymelt]

良い記事。高階関数のキモは「一度に一つのことしかするな」ということだと思う。一度に色々やってしまっているループが表現しづらくなるのでちゃんと分解することを要求する。その過程でメンタルモデルが整理される

[takahashim]

高階関数じゃなくても for (const product of products) { if (capDiscount(product)) { result = [...result, discount(product)]; }} みたいにするのが読みやすくて良いですよ、というふつうの話ではありますよね

[ssig33]

例が全然読みやすくなってないよくあるやつだ、類似例: https://qiita.com/yonetty/items/988af593152349ec2800

[nirasan]

この例そもそもProduct型がcanDiscountとかdiscountPriceをメソッドなりなんなりで持ってる方が自然じゃない？

[paradoxparanoic]

2025年にこのような議論が必要というのが関数型言語ブームの敗北。人類に叡智を与えることは無理だった

[mole-studio]

修正例見てもforで良かったな。変数増やして名前に頭ひねるよりifの上にコメント書く方がマシに感じる

[te2u]

mapやfilterは「何をしたいか」がシンプルでないとわかりにくくなる。分かりやすさを考慮すると、ループ処理自体を何度か繰り返すことになるけど性能面を考慮しなければならない。その過程で別法が見つかることがある。

[zyzy]

fold・reduce系も用途は一つなので、全てを曖昧にぶちこんだforでごちゃつかせるよりは整頓出来て分かりやすいと思うよ。大域脱出がある奴はforがいいが（flatMap駆使して出来る場合もあるけど、流石に面倒くさくなりがち）

[sa-yama321]

map/filterはforより全く読みやすくていいんだが、reduceはだめなんだよな。reduceがだめだとわからない人のコードはコードリーディングが数秒遅れるから、なかなか苦い

[hatest]

WHATとHOWを分離する話 と 高階関数 vs for文の話 は別ですよね？2つのテーマを分離したほうが読みやすいよ

[strawberryhunter]

自分の基準ではどうでもいいコードでは使ってるかな(Java, JavaScript)。forも for eachよりインデックスを使うパターンが結構ある。ついでにdo whileもたまに使う。

[suien42]

この議論、実際はプログラムに限らない「まず大枠から話してくれ」vs「頭から順を追って話してくれ」という対立なんじゃないかと思っている。

[hidea]

読みにくいと思ったことなかった

[ftype]

なおBiomeはforEach非推奨なんだよな〜

[hanagesan]

可読性を保ちながら並列化を導入する場合は使うけど、それ以外は個人の趣味の範疇を出ないので使わない

[dorapon2000]

“map や filter などの集合操作の高階関数は、ループという具体的な How を隠蔽し、そのコードで表したい What を宣言的に書けるようにします”

[zgmf-x20a]

LISPの時は気にならなかったけど、Rだとsapplyの中でのスコープがうまく使えずスクリプトが汚い私。

[nida3001]

これは単にmapとfilterっていうセマンティクスが理解しやすくよくできているのが主要因で、fold系の動作になると途端に難しくなるよ

[kiyo_hiko]

息をするようにmapcar使ってるのでforは読みづらい…気がするでもforってCommon Lispのdoマクロと似てるっちゃ似てるから読める。条件演算子のこの書き方はPerl Best Practice読んで慣れたのでとても読みやすいと思う。

[mayumayu_nimolove]

読みやすいというより処理が早いんだよ。あと読みやすいとかもう無くなるから。

[thesecret3]

動けばいいよ。在庫管理がしたいだけだ。

[shingo-sasaki-0529]

WHATとHOWを分離する例、個人的にはすごく読みやすくなったと思うし、切り出したHOW部分を単体テスト出来るというのもポイント高い。

[ryunosinfx]

非同期処理のjsの前ではあまりにも無力…※jsの仕様上なかなかしんどい

[kagerouttepaso]

IDiscountDecorator的なインターフェースで価格操作処理を抽象化するときなんかはこういう考え方必須になってくる。そこまでじゃないときは任意かなぁ、高階関数を使うというより抽象化の境界を意識する的な。

[hryord]

高階関数以前の問題としてifや三項演算子の書き方が酷い。頭いい人が書く独りよがりなコードっぽい。

[objectiveworker]

普通のmarkdownで書いて文章で説明してほしい。ナイトクラブで流すモーションタイポグラフィかと思ったわ。

[Yagokoro]

使ってるフォントが読みにくいがｗ

[spark7]

他人に見せるコードでしょうもないリガチャ効かせたフォント使ってると（個人的にだが）信頼度がだいぶ下がる

[fut573]

if(pj要員が実務経験3年以上の直接雇用に限定できる)｛｝を最初に判定しないと

[mushus]

めっちゃ分かる、そしてループでbreakが必要なパターンはだいたい別のこと一緒にやってたりするし、イテレーターのfilterとかmap以外の関数で代用できる

[Insite]

関数型プログラミングは機能ごとに切り分けないと読みにくい。for文の中に手続きをダラダラ書いたままのは手続き的プログラミングとしては読みやすい。

[atsushieno]

GCあり言語ではコレクションの完全コピーを回避するラッパーは十分に「ゼロコストに近い」と考えて良いので、values()に言及しているこの記事は十分配慮している。values()が機能を表さない名前なのは筆者の責任ではない。

[habarhaba]

mapやfilterが読みづらいと思ったこと無いな。for文でも良いのにreduceを使ってるのは一瞬止まることはある

[n_vermillion]

高階関数か否かより適切な関数切り出しの形の話のような…。

[kabakiyo]

この三項演算子を読みにくい人がいるとは！

[otoan52]

より多くの意味が残るのが高階関数で書くことの良さだと思うよ。全件をなめるのだという意図が明白になる。for文だと繰り返しと終了条件の組み合わせの結果、全件をなめることになります。と読み取らないといけない。

[kowa]

ループは形でわかるけど関数は文字を読んで認識しないとわからないからでは。画像的認知は効率いいからな