コードの至る所に命名が必要です。プログラマーとして、クラス、変数、関数、パラメータ、名前空間などに名前を付けなければなりません。以下に、命名スキルを向上させるのに役立つ20のヒントを紹介します。

20-naming-rules

1.意図を表現できる名前を使う

名前は、それが何をするのか、なぜ存在するのか、どのように機能するのかを教えてくれるものでなければなりません。意図を表現する名前を選ぶことで、コードを理解しやすくなります。

int d; // elapsed time in days

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

上記の断片では、変数dが何を指すのかはコメントからしか分かりません。そのため、コードを読む人はその意味を知るために、手がかりを得るべくそのインスタンスを探さなければなりません。ですから、この変数に適切な名前を付ければ、読者は瞬時にその意味を理解できるでしょう。

2.名前を選ぶのに時間をかけることを恐れない

意味を十分に説明できるまで、いくつかの異なる名前を試すべきです。時間をかけることを恐れてはいけません。後でコードを読む人(自分自身を含む)がその恩恵を受けるでしょう。さらに、説明的な名前は、モジュールの設計を頭の中で整理するのにも役立ちます。良い命名には確かに時間がかかりますが、長期的に見れば利点が欠点を上回ります。

3.名前をリファクタリングする

後の開発中に良い名前を思いついたら、ためらわずにすぐに変更しましょう。現在のIDEは名前のリファクタリングを非常に容易にしてくれます。

4.名前にノイズワードを入れない

例えばManager、Processor、Data、Infoおよび「何と呼べばいいのか分からない」という類義語は、すべてノイズワードです。上記のようなノイズワードを使う必要があるなら、命名が冗長すぎることを示しています。

5.名前を付けにくいクラス/機能に注意する

名前を付けるのが難しいクラスや関数は、コードスメルである可能性が高いです。それは次のことを示しています:

  • コードがやりすぎている。
  • コードが十分ではない。
  • 問題の理解が不十分で、先にさらなる情報を得る必要がある。

6.クラス名

クラスには名詞または名詞句の名前を付けるべきです。例えばCustomer、WikiPage、AccountとAddressParser継承元の親クラスには短くてインパクトのある名前を付けます。サブクラスの名前はもう少し長くし、親クラスとの違いを形容詞で記述します。例えばSavingsAccountAccountから派生したものです。

7.変数名

変数名も名詞であるべきです。それらは主に、指し示すクラスから派生します。ブール変数は述語の形で記述します。例えばisEmptyとisTerminatedこのようにすれば、if文で理解しやすくなります。

8.メソッド名

メソッド名は動詞または動詞句にします。例えばpostPayment()、deletePage()とsave()アクセサとミューテータには、それぞれ接頭辞getとsetを付けるべきです。ブール値を返すメソッドには接頭辞'is'を付けます。例えばisPostable()のように。これによりif文で理解しやすくなります。

9.スコープの大きさと変数名の長さ

変数名の長さはスコープの大きさと一致させるべきです。変数のスコープが非常に短い場合、変数名も短くすべきです。逆に、スコープが大きい場合は、変数名はより長く、より説明的にすべきです。

10.スコープの大きさとメソッド/クラス名の長さ

メソッド名とクラス名の長さはスコープと反比例させるべきです。パブリックメソッドは頻繁に呼び出されるため、短い名前の方が良いでしょう。プライベートメソッドはクラスのスコープ内でのみ呼び出されるため、長い名前はドキュメントとして機能します。このルールの例外は派生クラスの名前です。クラスがより派生しているほど、基底クラスの前に付けられる形容詞が多くなり、名前も長くなります。

11.一つの概念には一つの言葉

ある抽象概念に対して一つの言葉を選び、それを変えないようにします。例えば、異なるクラスで同等のメソッドとして、get()、fetch()とretrieve()混乱させます。一貫した語彙は、プログラマーがコードを操るための重要なツールです。

12.同じ言葉を異なる概念に使わない

第11点「一つの概念には一つの言葉」の原則に従えば、同じメソッド名を持つ多くのクラスを避けることができます。パラメータリストと各メソッドの戻り値が意味的に等価であれば問題ありません。同じ言葉を二つの異なる概念に使った場合にのみ問題が生じます。

例えば、複数のクラスでadd()メソッドを使用し、2つの既存の値を追加または連結して新しい値を生成します。もし後で、コレクションにパラメータを追加するaddメソッドをクラスに導入する必要が生じた場合、意味が異なるため問題が発生します。この新しいメソッドはinsert()と改名するのが最善です。

13.解決策領域の名前を使う

私たちが書くコードは、今後他のプログラマーが読む可能性があります。そのため、技術用語を使ってコードに名前を付けることは大きな利点をもたらします。例えば、アルゴリズム名、デザインパターン名、数学用語を適切に使うと、これらの命名方法は他のプログラマーがプログラムを理解しやすくし、共感を呼ぶ可能性が高いです。

14.問題領域の名前を使う

理解しやすい技術用語で名前を付けることがどうしてもできない場合は、問題領域から適切なコード命名を探すこともできます。将来あなたのコードを読むプログラマーがコードの意味に確信を持てないとき、それは問題の手がかりを提供します。

15.意味のある文脈を追加する

ほとんどの名前はそれ自体には意味がなく、コードを読む人がそれが何を指すのかを理解するには、文脈(クラス/関数/名前空間)の中に置く必要があります。場合によっては、名前の前に接頭辞を付けて文脈を補足する必要があるかもしれません。例えば、住所を表す変数がいくつかあるとします。firstName、lastName、street、houseNumber、city、stateとzipstateという変数だけを見ても、それが何を指すのかを推測するのは難しいです。良い解決策の一つは、これらの変数をAddressクラスにカプセル化することです。

16.根拠のない文脈を追加しない

意味が明確であれば、短い名前の方が通常は長い名前より優れています。ですから、余計な文脈を追加すべきではありません。クラス/パッケージ/名前空間から推測できる不要な情報を名前に付けるべきではありません。

17.エンコーディングを避ける

現在のIDEの強力さを考慮すると、型やスコープ情報を変数名やクラス名にエンコードする必要はもうありません。これには、インターフェースにIを追加する必要がないことも含まれます。コードを使うユーザーは、自分のクラスがインターフェースに渡されていることを知る必要がないからです。どうしてもエンコーディングを使う必要があるなら、インターフェースではなく実装に対してエンコードするのが最善です。

18.誤った情報を避ける

誤った情報を提供してはいけません。コードを読む人を誤解させるからです。実際には配列を保持している変数にaccountListと名付けると、誤った結論に導かれやすくなります。

19.発音できない名前を使う

プログラミングは社会的な活動であり、発音できない名前を使うと議論の妨げになるだけです。

20.検索しやすい名前を使う

短くて一般的な名前を使うと、コードベース内で物事を検索するのが難しくなります。これはコードの操作やリファクタリングに大きな影響を与えます。

最後に、異論があれば、遠慮なくご教示ください。

出典:http://www.codeceo.com/article/20-naming-tips-programmer-know.html