Naming -名前付け-

プログラミングで最も重要な技術の一つが、名前付けです。
且つ、センスが問われるものなので、上達は難しいものでもあります。
この記事では、様々な文献から抽出した名前付けに関する情報を雑多にまとめました。

-名前重要-
ソフトウェアの設計のアプローチとして、『まず名前から入る』というのは、あまり語られていない秘訣としてもっと広く知られても良いように思います。
- まつもとゆきひろ 『プログラマが知るべき９７のこと』

コミュニケーションの基礎

名前は、コミュニケーションの基礎となるものです。
私にもあなたにも名前が無ければ、疎通することは困難になります。
名前をコミュニケーションの基礎と見た場合に重要なルールは以下の通りです。

• 発音可能であること
• 検索可能であること

※現実世界のみであれば検索可能じゃなくても良いかも知れません。
プログラミングは、チームや複数人で行うことのほうが多いと思います。その際、コードがコミュニケーションのツールとなるので、発音・検索可能でないと、不便極まりないです。生産性がかなり変わってきます。

ある会社でgenymdhmsという名前を使っていました。
このため、「ジェン ワイ エム ディー エイチ エム エス」といいながら仕事をする必要がありました。
- ロバート C. マーチン 『Clean Code』

ガイドライン

システムハンガリアンは使用しない

発音可能な名前を付けたいのであれば、システムハンガリアンはやめたほうが良いと考えます。
システムハンガリアンとアプリケーションハンガリアンは意味が違うので注意してください。アプリケーションハンガリアンに関する良い文献は間違ったコードは間違って見えるようにするです。

略語および、頭字語は使用しない

一般的に、識別子に略語または頭字語を使用してはいけません。名前については簡潔さよりも読みやすさのほうが重要です。一般的に理解されていない略語および頭字語を使用しないことも同様に重要です。すなわち、ある分野におけるエキスパートではない大多数の人々は、それが何を意味するのかすぐにはわからないのです。

-Krzysztof Cwalina,Brad Abrams 『.NETのクラスライブラリ設計』

例えば、UIや、XMLは、広く一般的に受け入れられています。これらはコード内に登場しても、理解を妨げる要因にはなりません。
AppleのCoding Guideline for Cocoaには、推奨する略語がまとめられています。Acceptable Abbreviations and Acronyms

Appleが公開しているObjective-Cのクラスライブラリ群は、クラス名にPrefixをつけています。
UIViewや、NSStringです。これらは、Objective-Cが名前空間を持たないことから、仕方なくつけているのだと理解しています。（※ちなみに"NS"は、"NeXTSTEP"の略です。)

大文字と小文字の使い分け規約

検索性という意味では、大文字小文字の使い分けは重要になります。大文字と小文字の使い分けに関しては、MSDNが非常に参考になります。

Code Naming

ユビキタス言語/専用の言語

コード内の、とりわけモデル層においては、ユビキタス言語を名前付けに用いるべきです。ドメインの領域とプログラムを分けて考えない。プログラムを、プログラムっぽくしないことが重要です。何のためのプログラムなのか、アプリケーションなのかを考えると、自然とモデルが洗練されてくるような気がします。
この考えは、達人プログラマーでは、『専用の言語』として紹介されています。

常にアプリケーション領域のボキャブラリーを使ったコード記述を試みましょう。-中略-さらにこれを推し進めれば、アプリケーション領域のボキャブラリー、シンタックス、セマンティックスーつまり専用の言語を用いて実際にプログラムを行うこともできるのです。
-アンドリュー・ハント/デビッド・トーマス『達人プログラマー』

クラス名は名詞と動名詞

クラス名は基本的には名詞です。
ドメイン駆動設計の中に、サービス(Services)というパターンが出てきます。
これはすごい便利です。ユビキタス言語ではないけど、ソフトウェアとして必要な処理群ってアプリケーションを普通に作る上で絶対出てくると思うのです。簡単な例だと、CSVパーサーとか、Windowsならレジストリアクセサとか。
これらは名前の最後にServiceを付けます。
CSVParserは、しっくりくるのでOKですね。CSVParingServiceより良い感じがします。
RegistoryAccessorは、どうでしょう？"Accessor"ってあんまり出てこない感じがします。そうゆう場合は、RegistoryAccessingServiceか、AccessingとってしまってRegistoryServiceですね。
役割の名前を付けられなかったら、動名詞にして末尾にServiceをつけると格好良くなります（笑

メソッド名は動詞から始める

これは有名ですね。「メソッドはそのオブジェクトに命令を下すもの」なので、命令型が良いのです。なので動詞からすぐはじめる。
以下のリストでほとんどカバーできていると思います。

名が体を表さないのはNG。Getメソッドなのに、メソッド内でSetしちゃっているとか良くみかけるコードです。

メソッド名にてメソッド内の処理を具体的に表現しちゃう

これは割りと最近知ったテクニックで、オープンソース見るとよく出てきますね。
例えば、
.NETでは、CreateDirectoryというメソッドがありますが、これをWrapして、
もし存在しなかったらディレクトリを作るというメソッドを作る場合に
CreateDirectoryIfNotExists
とか、英文っぽいメソッドですね。長くなりすぎると微妙ですけど。

コード中の名前に関するガイドラインやテクニック

一般的な名前付けは、MSDNが参考になります。
また、日本語でわかりやすい例とともに紹介されているOkapiも参考になります。boolean型を返すメソッド名等。
リーダブルコードは、ページ数も少なく持ち運びも便利です。挿絵はあまり好きになれませんが。。。

意図の明白なインターフェース

ある開発者があるコンポーネントを使用するために、その実装についてじっくり考えなければならないのであれば、カプセル化の価値は失われる。
エリック・エバンス 『ドメイン駆動設計』

メソッドの型・名前・引数名を駆使して、そのメソッドの内部詳細を知らずとも使えるようなインターフェースを用意する必要があります。エリック・エバンスは、そのことを意図の明白なインターフェースとして紹介しています。

参考書籍

Kevlin Henney『プログラマが知るべき９７のこと』
ロバート C. マーチン 『Clean Code』
Krzysztof Cwalina,Brad Abrams 『.NETのクラスライブラリ設計』
アンドリュー・ハント/デビッド・トーマス『達人プログラマー』
Dustin Boswell/Trevor Foucher『リーダブルコード』
エリック・エバンス 『ドメイン駆動設計』
Jaroslav Tulach 『APIデザインの極意』
Namingのプレゼン資料