More than 1 year has passed since last update.

Naming -名前付け-

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

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

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

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

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

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

ある会社で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をつけると格好良くなります(笑

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

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

動詞名 日本語表現 主な戻り値
Get 取得する オブジェクト
Set 設定する void
Update 更新する void(updateした件数返す場合も)
Delete 削除する void(deleteした件数返す場合も)
Insert 挿入する void
Select 選択する オブジェクト
Find 選択する オブジェクト
Add 追加する void
Remove 削除する オブジェクト
Clear クリアする void
Append 追記する void or 追加後のオブジェクト
Trim 整形する オブジェクト
Compare 比較する 比較結果(-1,0,1)
Concat 結合する オブジェクト
Split 分割する オブジェクト
Enumerate 列挙する 配列
Move 移動する void
Copy コピーする void
Create 作成する オブジェクト
Make 作成する オブジェクト
Generate 作成する オブジェクト
New 生成する オブジェクト
Build 組み立てる オブジェクトもしくはvoidで引数に与えられた変数を組み立て
Flush フラッシュする void
Begin 始める void
End 終わる void
Initialize 初期化する void
Load ロードする void
Merge マージする オブジェクト
Read 読む オブジェクト
Write 書く void
To 変換する オブジェクト
Convert 変換する オブジェクト
Accept 許容する void
Fill 満たす void
Apply 適用する void
Show 表示する void
Union 和集合を取得する オブジェクト
Intersect 積集合を取得する オブジェクト
Do 実行する void
Run 実行する void
Shutdown シャットダウンする void
Save 保存する void
Cancel キャンセルする void
Refresh リフレッシュする void
Execute 実行する bool(成功か失敗か)
Resolve 解決する オブジェクト
Invoke 呼び出す オブジェクト
Handle ハンドルする オブジェクト
Raise 呼び出す void
Is 〜かどうか? bool
Contains 含んでる? bool
Exists 存在する? bool
Verify 確認する/評価する bool(voidでNGなら例外でもいいかも)
Validate 検証する bool
Try 試みる bool(voidでNGなら例外でもいいかも)
Has 持っている? bool
Equals 比較する bool
Can できるか? bool

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

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

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

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

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

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

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

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

参考書籍

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