コードの中では至る所に命名が必要です。プログラマーとして、クラス、変数、関数、パラメータ、名前空間などに名前を付けなければなりません。以下に、命名能力を向上させるための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とzip。state という変数だけを見ても、それが何を指すのかを推測するのは困難です。より良い解決策は、これらの変数を Address クラスにカプセル化することです。

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

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

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

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

18.誤った情報を避ける

誤った情報を与えてはいけません。コードを読む人を誤解させるからです。実際には配列である変数に accountList という名前を付けると、人は誤った結論を導き出しやすくなります。

19.読み上げられない名前を使う

プログラミングは社会的な活動です。読み上げられない名前を使うことは、私たちの議論を妨げるだけです。

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

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

最後に、もし異なるご意見があれば、遠慮なくお聞かせください。

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