- 現代のソフトウェア開発文化では、プロジェクトやライブラリの名前が機能と無関係な恣意的な単語で埋め尽くされつつある
- かつてはgrep, awk, sed, FORTRAN, COBOLのように、名前が機能や目的を直接説明していたが、最近では意味のない名称が氾濫している
- こうした傾向はGitHubとスタートアップ文化の拡大のなかで加速し、名前と機能の結び付きが完全に断たれてしまった
- 理解コストと認知的負担が増大し、開発者は各ツールの役割を把握するために不要な探索を繰り返すことになる
- この記事は明確で機能中心の命名規則の復権を求め、技術ツールではブランドよりも明瞭さと専門性が優先されるべきだと強調する
ソフトウェア命名慣行の変化
- Richard Stallmanは2022年のEmacsConf講演で「覚えやすい名前」の重要性に触れ、パッケージ名は何をするものかを示すべきだと強調した
- Emacsのエコシステムでは伝統的にdired（ディレクトリエディタ）、**eshell（Emacsシェル）**など、機能ベースの命名慣行が維持されてきた
- しかし現代の開発者は、無作為な名詞、神話上の存在、架空の人物のような名前をツールに付ける傾向がある
- これは他の技術分野であれば専門性の欠如と見なされる行為である
意味のない名前の問題
- 例として「Viper」「Cobra」「Melody」「Casbin」「Asynq」といったツール名からは、機能をまったく推測できない
- 著者は、友人のインフラ説明を理解するために検索までしなければならなかった経験に言及している
- 他の工学分野では、名前が構造や機能を説明している
- 例: Golden Gate Bridge、Hoover Dam、I-beam、butterfly valveなどは形状や役割が明確に表れている
- 化学分野のIUPAC命名法のように、名称が正確に一つの対象を指すよう規定されている
- 例: 2,2,4-trimethylpentaneはただ一つの分子を意味し、恣意的に「Steve」とは呼ばない
過去の命名規則と現在の断絶
- 1980年代にはgrep, awk, sed, cat, diffなど、機能ベースの略語が主流だった
- FORTRAN, COBOL, BASIC, SQL, Lispなどのプログラミング言語名も目的を反映していた
- 2010年代以降、意味のない名前の拡散が始まった
- MongoDBのように一部は機能や語源との関連があったが、その後GitHubとスタートアップ文化のなかで無意味な名称が急増した
- Googleのようなブランド中心の成功例を模倣しようとする傾向が原因として指摘されている
認知コストと開発効率の低下
- libsodiumのような名前は機能を推測しづらく、開発者はコンテキストスイッチを繰り返すことになる
- 「なぜsodiumなのか？」を解釈するのに不要な時間が費やされる
- プロジェクトの依存関係が多いほど、こうした**認知税(cognitive tax)**が積み重なる
- 著者は、「Viper, Cobra, Melody...」のような文を処理するとき、意味のないトークンの解釈に精神的資源が浪費されると指摘する
よくある反論とそれへの反駁
- 「覚えやすい名前の方がマーケティングに有利だ」→ 開発者向けツールは消費者向け製品ではなく、機能の明確さの方が重要である
- 「説明的な名前は退屈だ」→ 退屈さは明確さの代償として許容できる。外科器具も退屈だが正確である
- 「面白半分で付けているだけだ」→ その『面白さ』の代償はすべての利用者が払うことになり、業界全体の時間の浪費につながる
- 「良い名前はもう使い尽くされている」→ 名前空間、接頭辞、複合語などで解決でき、少なくとも機能と関連した名前を選ぶべきである
これからの方向性
- 問題は悪意というよりも文化的変化の結果として説明される
- プログラミングが企業中心からコミュニティ中心へ移るなかで、社会的規範が弱まった
- 解決策は命名規則の文化的復元である
- 規制よりも専門性の回復、教育、社会的圧力を通じた改善が必要だ
- ライブラリ名は機能を反映すべきであり、必要であれば複合語や冗長な表現も許容される
- 例: 「http-request-validator」は「zephyr」よりはるかに明確である
- マスコットと名前は分離すべきである
- 例: PostgreSQLは象のマスコットSlonikを使っているが、名前自体は機能的な意味を保っている
- ブランディングが重要な消費者向け製品でないなら、明瞭さと専門性を優先すべきである
- 「好きなアニメキャラクターの名前」を付ける前に、「土木技術者なら橋梁システムにこんな名前を付けるだろうか？」と自問すべきだ
- 結論として、無意味な名称の乱立を止め、明確な専門言語へ立ち返るべきである
- 明確さは退屈さではなく、利用者の時間と認知資源への敬意である
7件のコメント
Awkも機能ベースの名前というにはちょっと……
例を書かなければ、説得力は10％くらい上がった気がする…。
ある程度は同意するけど、名前を付けるストレスを受けたくないんだと思う
使い勝手のいい名前は、もう誰かがだいたい使っている。
emacsが何の略かご存じの方いますか？ 意味はあるにはあるのでしょうが、頭字語の名前は見ただけでは分からないし、そもそも名前なのに……。それに、機能だけで名前を付けるには、今やプロジェクトが多すぎますよね。GitHub のせいにしているのを見ると、ただの RMS 式の言いがかりですね（笑）
Hacker Newsの意見
GNU版のYaccはBisonと呼ばれる。Pineは「Pine Is Not Elm」の略で、UNIXはMULTICSの語呂合わせであるUNICSに由来する。ddが何の略かは知らないし、nanoはpicoのクローン、Postfixは「post」と「bug fix」を組み合わせた語だ。C++はCのインクリメンタル版で、CはBの後継、BはBCPLの後継だ。実のところ、開発者たちは「命名の哲学」を失ったのではなく、最初から持っていなかった。逆に、Clang、LLDB、jq、fzf、locのような現代のプロジェクトは良い名前の例だと思う。mise-en-placeはmiseの機能を完璧にたとえている
key=value形式の構文になっているgrep、awk、sed、cat、diffなどのUNIXコマンドは機能的または体系的な名前だったが、実際にはdiffくらいしか直感的に推測できない。awkを良い名前と呼ぶのは誇張だ
-libertyオプションでリンクできるように付けられた名前だ「技術分野でこういう命名はキャリア自殺だ」という主張には反論したい。米国国防総省のコードネーム一覧を見ると、むしろ意図的に不透明な名前が多い。Hoover Damも最初はBoulder Canyon Projectと呼ばれていて、名前は機能を説明していない。RequestsよりReitzlibの方が良い名前だろうか？ 結局、名前は文脈次第だ
awkのような名前は実際には良い名前ではない。単なる著者のイニシャルにすぎず、機能をまったく伝えない。今はタブ補完もあるのだから、そこまで短くする必要もない
私はこの反論記事に共感する。外部識別子は時間がたつと意味が変わるので、最初から正確に記述する名前は長持ちしない。しかも「X Manager」「X Service」のような名前が多すぎて区別しづらい
私は自動車OEMでエンジン較正エンジニアとして働いていたが、変数や関数はすべて略語だった。最初の1か月は頭が爆発しそうなくらい疲れた。結局、同僚が「これは新しい言語を学ぶのと同じだ」と言ったが、本当にその通りだった。つまり、技術的な名前が多いからといって認知負荷が減るわけではない
「機能的な名前はマーケティングより良い」という主張には同意しにくい。機能ベースの名前は結局、終わりのない略語の海を生む。ABDCとADBCを取り違えるような事態が起こる
HNにこういう記事が上がってきたのが不思議だ。awkのような名前を例に挙げて「命名の本質を失った」と主張するのは矛盾している。結局、かわいい名前に対する個人的な反感に見える。ちなみにこのコメントはFirefoxで書いているが、名前だけ見てもWebブラウザだとは分からない
「説明的な名前は退屈だ」という主張については、手術室の器具も実際には人名から付けられている。Adson、Allis、Babcock、Kocherといった名前は機能をまったく説明しない。結局、慣れれば意味が生まれる。awkは微妙だが、diffは良い例だ
「私たちの分野はランダムな名詞の動物園のようだ」という主張に対して、私は面白い名前が好きだ。私のプロジェクトWimseyはデータテストライブラリだが、名前だけでは分からない。それでもPython、Cron、Zellijのように愛情とユーモアのある名前が好きだ。技術は結局人が作るものなのだから、楽しさが必要だ。「brown-dog-2」より「cookie」の方が人間味がある