単一の責務を帯びた関数の名前
単一の責務を帯びた関数の名前が付けづらい、というのは良く耳にします。
もしかしますとですが、
- 責務にまともな名前が付かないのは本質的
で、
- 責務とは、メソレベルの情報となり、本質的に混ざり物
（追加開始 2025/6/11 PM7）この記述は誤りです。後述の「関数型の誤解 １」にて説明いたします。（追加終了）
なので、
- 「まともな名前をつけさせてくれず、意味がわからない」方が自然で、
- その方が順当な振る舞い
では無いかと思う様になりました。
1つの責務内で、混ざった複数の手続きが、それぞれ望む名前を持ち、その混ざり物の、混ざり具合も、時々変化する、となれば、責務の名前を付けるのが困難である、という方が自然です。
鉄道に例えるなら、
鉄道に例えるなら、
- 旅客に案内する内容で、保線をする
様な物では無いでしょうか？ 責務は万人に分かり易いですが、粗過ぎると思います。
（実用的な）責務には複数の手続きが同居し、複数が同居しているからこそ、実用的な責務となり得るのだと思います。
もちろん鉄道の様に路線がかなり固定だと、旅客に案内する内容でもやれるのかも知れませんが、プログラム開発の場合（以下、例えですが、）、
の様な事も頻発するので、プログラム開発の分野では、さらにやれなくなると思います。
原因（目的）が複雑なら、結果（手続きの連なり）も複雑になる方が自然なので、この様な路線のつながりに成る事が有っても、仕方無い場合が有ると思います。
それなら1責務、1手続きにすれば？
私は、1980年代の最後の方から、プログラマーになりましたが（もちろんCOBOLの）、
先輩が第一に言ったのは、
- 機能化はいい加減にしておけ
という物でした。
機能化とは、そのプロジェクトでの、
- 機能をくくり出して、関数に仕立てる
事を意味する言葉でしたが、これだけは厳命されました。
機能化でみんなが納得した物は、「西暦→和暦」、「和暦→西暦」変換の機能位の物でした。（これが2000年問題の核心の1つでは有りました。）
要するに、1手続きを1関数にしても、実用的な責務とはならず、さらに共通で使える様な、みんなが納得出来るものにもならず、
非常につまらない、くだらない物にしかならないのです。そんな事は1980年代には、すでに分かっていました。
結論
責務の名前が"まともに"付かないのは、それで原理的に正しく、その方が自然です。
これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
