なぜ命名規則が必要なのか

コーディング規約とは

　コードに統一性を持たせ、可読性を向上させることにより、コードリーディングのコストを削減するものです。

　通常、プロジェクトでは、コーディング規約に従ってコーディングが行われます。
　Google Java Style Guideなどの優れたコーディング規約が公開されていたりしますが、プロジェクトによっては適さないものもあると思います。

　そのため、プロジェクト内で細かいルールを制定した独自のコーディング規約を作成することで、コーディングの効率を上げ、最大限開発に集中することができるようにしています。

　今回は、コーディング規約の中でも命名規則に絞ってまとめていきたいと思います。

命名規則

　命名規則は、プロジェクトによって独自のルールがあるものですから、ここで述べるのは概念的なものに留めます。

　javaでは、変数名の定義には、殆ど自由と言って良いほど多数の文字が使えます。
　たとえば、日本語を使ってみましょう。

import java.util.*;

public class Main {
    static final List<利用者> 利用者達 = new ArrayList<>();

    private static class 利用者{
        private int 識別子;

        public 利用者(int 識別子){
            this.識別子 = 識別子;
        }

        public int 識別子取得(){
            return 識別子;
        }
    }

    public static void main(String[] args) throws Exception {
        利用者追加(1);
        利用者追加(2);
        利用者追加(3);

        for(利用者 _利用者 : 利用者達){
            System.out.println(_利用者.識別子取得());
        }
    }

    public static void 利用者追加(int 識別子){
        利用者達.add(new 利用者(識別子));
    }
}

　結果

1
2
3

　もしかして、「読みづらい」「気持ち悪い」と感じましたか？
　それは、ごく自然な感想かもしれませんが、これを合理的判断の上で使用しているプロジェクトも実際に存在するそうです。

　テストコードにおいては、メソッド名がそのまま結果に表示されることから、直観的かつ誤解を生みにくいという理由で、日本語を使うことを推奨していることもあります。

　ですが、それらは常に少数派です。あなたがプロジェクトのコーディング規約を自由に書き換える権力を持っていたとしても、賛同を得るにはかなりの長い時間と、大変な努力が必要です。そのコーディング規約のせいで優秀なエンジニアがプロジェクトから離脱してしまうリスクすら考慮しなければなりません。

　コーディング規約は常にプロジェクトメンバーの共有物であるべきです。
　

ハンガリアン記法

　現在は非推奨とされているハンガリアン記法ですが、発明当時は大きくプロジェクトに貢献していました。恐らく、その当時から現代にわたり最も有名な命名規則と言えるでしょう。

ハンガリアン記法とは

　ハンガリアン記法には、アプリケーションハンガリアンとシステムハンガリアンの区別がありますが、一般的には、ハンガリアン記法といえばシステムハンガリアンを指します。

　変数の型名を表す文字列を、各変数名の接頭辞に付与することによって、変数名を見ればそこから型が推測できる、というものです。一例を以下に挙げます。

型	変数名	ハンガリアン記法
Integer	id	iId
String	name	sName
Long	date	lDate

　現在の豪華な開発環境と違い、当時はコンパイラすら貧弱なもので、エラーをひとつ探すことすら大変なコストが掛かりました。

　しかしこのハンガリアン記法を使えば、非常に簡単に間違いを探すことができます。たとえば以下の例です。

String sId = "A1234";
int iId = 1234;

sId = iId;

　こう見ると、変数宣言を見るまでもなく、String型にint型を代入しようとしているのが一目瞭然なわけですから、当時は大きなメリットでした。

　しかし、近年、開発環境やコンパイラが高機能化されたことにより、容易に型や、エラー箇所を知ることができるようになりました。ハンガリアン記法は、改修コストの増大と可読性の悪化といったデメリットのみを残すのみとなり、一気に負の遺産へと成り下がってしまったのです。

　未だにハンガリアン記法を取り入れているプロジェクトもあると聞きますが、現代の環境においては、採用するメリットは皆無と言えるでしょう。

javaの命名規則

　一般的に広く知られているのは以下のとおりです。

種類	命名規則	例
クラス名	アッパーキャメルケース	UserModel
変数	キャメルケース	userName
メソッド	キャメルケース	getUserName
定数	スネークケース	MAX_CONNECTION

　規則を定めることで、コードが何を示しているかがわかります。アッパーキャメルケースは必ずクラス名にしか使われないと分かっていれば、宣言時にそれがフィールドなのかクラスなのか混同することはありません。
　変数とメソッドは同じ命名規則を持っていますが、メソッドは引数が無い場合でも必ず後ろに（）が付くので、こちらも混同はありません。
　スネークケースによりそれが定数であると分かっていれば、その変数を再度変更しようとはしません。

　つまり、このように統一された規約は、無用な確認を避けることと、エンジニア同士の相互理解を助け、非常に良い影響を与えるものと言えます。

　また、メソッド名は下記のようなルールに基づいて命名が行われます。

目的	命名例
取得するメソッド	get○○など
検索するメソッド	find○○など
boolを返すメソッド	is○○,can○○,has○○など

　たとえば、DAOクラスを作成するとして、IDを検索条件に名前を取得してくるようなメソッドは以下のように命名します。

public String getUserNameById(int id){} // findUserNameByIdなども可

　英語で自然に読めるような名前になっています。メソッドが何をしてくれるか、何を返してくれるか一目瞭然です。

　このように、命名規則がきちんと制定されていれば、ある名前が何を示すかすぐに分かるというメリットがあります。

まとめ

　命名規則は、可読性向上および改修コストの削減のため、プロジェクトに統一性を持たせることを目的としています。

　規約の良しあしは別としても、一旦規約が制定されたら、すべてのプロジェクトメンバーがこれを守らないと意味がありません。もし一人でもこの規約を守らないメンバーがいると、プロジェクトのソースコード品質は目を当てられないほど粗悪なものとなります。

　プロジェクトにとって、より良い命名規則の制定を心掛けたいものですね。