2237
@Koki_jp

Naming -名前付け-

この記事は最終更新日から5年以上が経過しています。

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のプレゼン資料

2237
ユーザー登録して、Qiitaをもっと便利に使ってみませんか。
  1. あなたにマッチした記事をお届けします
    ユーザーやタグをフォローすることで、あなたが興味を持つ技術分野の情報をまとめてキャッチアップできます
  2. 便利な情報をあとで効率的に読み返せます
    気に入った記事を「ストック」することで、あとからすぐに検索できます
Koki_jp
アジャイルコーチ@Red hat、スクラムマスター、プログラマ。 C#, C++, SQL,DDD,UnitTest,DI好きです。 Agile Coach, Scrum Master/Certified Scrum Professional/Certified LeSS Practitioner

コメント

役割の名前を付けられなかったら、動名詞にして末尾にServiceをつけると格好良くなります

それは見掛けを取り繕っただけで実質的にまともな名前をつけることを放棄していると思うのですが...

8

xxxService(), xxxManager(), xxxControl()など名前付けを放棄した実装は結構見かけます。かといって、どういう名前をつければ名前からその機能がわかるようになるのか、と言われると難しいものです。

1

皆様、コメントありがとうございます。

私は子供が生まれるというときに名前を数ヶ月悩みました。色々と名前付けの本を読んだり、たくさん候補を出したり。でも結局悩んでも実際に生まれてきてくれた子供の顔をみて、候補にはなかった名前を選びました。最後は直感とフィーリングでした。

名前付けって本当に奥が深いと思います。
ソフトウェアの中でも真に「ソフト」な部分なんだなとよく思います。唯一の解答がないし、とっても人間に近い部分かと。顧客の要求、組織の成熟度、個々人の能力、使用言語、様々なものに左右されると思います。だからこそ面白い部分かとも思います。
ソフトウェア開発の面白さの一つに「自分の生み出したクラスやメソッドに名前を付けることができる」が挙げられるかも知れません。言い当て妙な名前を思いつくと、本当にわくわくしますよね。

実際の開発現場では名前付けに割けられる時間はごく短いものかと思いますが、(数ヶ月は絶対悩めませんよね(笑))
この記事が皆様の開発現場で何かのお役に立てれば幸いです。

0

validate の日本語表現は「検証する」が適当ではないでしょうか。

2

メソッド名は動詞から始めるの初期化するの動詞名について
誤)initalize
正)initialize

1

「メソッドはそのオブジェクトに命令を下すもの」なので、命令型が良いのです。

なるほどと思う反面,すべてに当てはまるわけでもないと思いました。is, has とか。

ところで,「Verify」が「評価する」は何かの間違いではないでしょうか。「Verify」は「確認する,照合する」,「Evaluate」が「評価する」のほうがしっくりくる気がします。

4
あなたもコメントしてみませんか :)
ユーザー登録
すでにアカウントを持っている方はログイン
記事投稿イベント開催中
新人プログラマ応援 - みんなで新人を育てよう!
~
Microsoft Igniteに参加してイベントに関する記事を投稿しよう!
~
ユーザーは見つかりませんでした