Re: なぜ省略はダメなのか

『なぜ省略はダメなのか』に対するエントリです。

とは言え特に反論があるわけではありません。まぁ強いて言えば一般的な省略(AdministratorをAdmin)と一般的でない省略(UpdateをUpdt)の区別を付けることが非常に難しい(=コストがかかる)事を軽視しているように見える点はちょっと不満ですが、趣旨や結論に不満はないです。
で、省略を考える上で検討すべきことってもっと他にもいっぱいあるのではないかなという(勝手な)補足エントリです。

２つの省略

まず、省略には「省略する対象となる語」と「語を省略する方法」の２種類の意味があります。例えば、ハンガリアン記法等は後者の「方法」についてです。対して、『なぜ省略はダメなのか』では「方法」は一切述べられず、「対象」にスポットを当てています。これは、

大切なのは“省略がダメ”とかではなく、“シンプルに伝わか？”という事です。

という言葉から、省略の評価は事後的な観測によって決定されるという期待によるものだと思います。
「方法」を規定するメリットはコストでしょう。名前付けのたびにいちいち「この省略は文脈や組織を考えた上で適当か？」を自問する事は(良し悪しは別として)コストが掛かります。後は統一性を得られるといった効果も期待できそうです。
「対象」を(事後的に)考えるメリットは自然さでしょう。そもそも自然言語は統一性のかけらもない複雑さの塊みたいなものなので、統一的なルールの下での運用ではどうしても歪が生まれます。デメリットは高コストであることで、特に組織コミュニケーションの観点から言えば個人で完結して省略語を評価する事は危険です。そうなると変数一つ定義するのに判子が必要になってしまいます。もちろんこれは極端な例であり、現実ではいずれかで妥協が必要でしょう。
ここでは元エントリに対するリスペクトから「方法」ではなく(主に事後的な)「対象」から省略を考えます。

省略語の種類

全ての省略語に対して「適切かどうかよく考えましょう」だと話がそこで終わってしまう上に面白くもありません。そこで、省略された語を目的や用途からいくつかに分類してみましょう。

日常的な省略

そもそもプログラミング言語は借用語の塊です。プログラミング言語が独立して(人が解釈する)「意味」を持つ事はありません(機械が解釈する「意味」を考えることは可能です)。プログラマは借用語が(独立に)持っている「意味」と機械が解釈する「意味」の組み合わせの事後的な分析によってプログラムの総合的な「意味」を解釈しています。ですので、借用語の意味だけではプログラムの総合的な意味はカバーしきれませんが、ここではひとまず借用語の意味に限定して考えます。
大抵のプログラミング言語の借用語というと、英語です。元エントリでも挙げられているように、AdminやIdなどが考えられます。
日常的な省略に関しては人が持つ常識に依存せざるを得ないでしょう。元エントリが対象としている省略はこれです。
１つ補足しておくと、メタ的な借用をどう扱うかという問題があります。例えば、日本語には多くの英語が借用語として入っています。IDも「アイディー」として多くの日本人が日常的に使っています。さて、日本人の言う「アイディー」と"Identifier"は同じでしょうか？例えば、idは連番、それも自動連番のようなものとして使用し、identifierはよりドメインに深く紐付いた識別を意味する、といった使い分けは妥当でしょうか。この使い分けを肯定した場合、与えている意味が異なるので厳密にはidはidentifierの省略語とはなりません。つまり、１つのプロジェクトでidとidentifierが同居する事になります。
また、「英語」の意味と日本で使われている「借用語としての英語」の意味がズレている場合、どちらに準ずるべきでしょう。元エントリと同一ブログ内のエントリである『testとtestingの違い』では英語の意味に準ずる旨の主張をしています。これもやはりコスト問題がありますし、組織によっては現実的でない場合もあるでしょう。

技術的な省略

プログラマであればIOはInput/Outputの省略語であることを期待できます(まぁこの例だとプログラマでなくとも期待できるでしょうね)。そして、PCはPersonal Computerです。しかし、コンパイラ作者の場合はProgram Counterの略である事は自明です(ニッチな分野に行けば行くほどこのようなドキッとする省略に出くわします)。
コードの管理をプログラマが行っている限り、そのコードにプログラマが通じると期待できる省略語を記述する事は正当化出来そうです。しかし、UI周りのコードはどうでしょう。例えばHTMLやCSSではデザイナと協力する必要がありそうです。その場合は技術的な省略は控えるべきかもしれません。

慣習的な省略

これはその省略が閉じた分野において慣習化した場合です。最も有名なものはC言語のfpでしょう。これがFile Pointerの略である事はC言語プログラマであれば十分期待できます。その他、繰り返し処理に現れるiはIndexの略です。また、無名関数において仮引数をxとするのは「未知なるもの」という数学由来の(由緒ある)慣習です。
これは人によっては批判の対象です。特にfpを許さない人は一定数いそうですね。また、これらの慣習は、慣習であるかぎり環境や文化、特に言語に強く依存します。例えば、fp擁護派だがそれはあくまでもC言語においてであって、C以外でfpなんて使ったら自分だって怒る、という人もいるでしょう。

ドメインに依存する省略

最後に、ドメイン、つまり問題領域に依存する省略はどうでしょう。例えばpcをProgram Counterの略だとするのは技術的な省略でもあり、レジスタマシンというドメインに依存する省略でもあります。
エリック・エヴァンスのドメイン駆動設計においてエリック・エヴァンスは「ユビキタス言語」という概念を提唱しています。簡単に言うと、プロジェクト内部でドメインに依存する言葉を積極的に導入し、プロジェクトとクライアントが共同でユビキタス言語という辞書を作ります。ドメインに造詣の深いクライアントはドメインエキスパートとしてユビキタス言語の策定やプロジェクト内部でのユビキタス言語のドメイン意味上での正しい運用に責任を持ちます。こうすることでクライアントとプロジェクトとの間で別々の専門用語を持つ言語の誕生を防ぎ、コミュニケーションを円滑に進めようとするものです。
この時、ドメインエキスパートが省略語を使用していた場合、ユビキタス言語では省略語をやめるべきでしょうか。しかし、そうなれば各々は別の専門用語を使う事になります。もちろん、それらは省略されているかどうかにしか違いがなく、意味は同じであるため無視できる問題だと考える事も出来ます。

まとめ

最初に言ったとおり、元エントリの結論に異論は無いため、このエントリのまとめも「よく考えてネーミングを考えましょう」と言うしかないわけですが、まぁ何か思考のたたき台にでもなれば幸いです。
また、「よく考えてネーミングを考えましょう」は正論ですが、地獄への道は善意で舗装されているとも言うので全てのネーミングについて逐一考え続けることもどうかと思います。
あとこういう「正論を言えばそうだけどそれだと面白くもない」問題についてみんなもっとカジュアルにあーだこーだ言えば良いと思います。

宣伝

『例外 Advent Calendar 2014』というAdvent Calendarを主催しています。例外機構やエラー回復などを語り合いたいのですが、今のところ参加者が僕１人です。とても悲しいので暇な人は参加すれば良いと思います。