その名前、未来の自分を苦しめますよ？読みやすいコードを書くための命名規則入門

2025年9月17日

この記事は、読みやすいコードを書くための実践ガイドシリーズの一つです。コードの品質を向上させるための基本的なテクニックを紹介していきます。

こんにちは。ソフトウェア開発において、私たちはコードを書く時間よりも、他人の（あるいは過去の自分の）コードを読む時間の方がはるかに長いと言われています。その「読みやすさ」を大きく左右するのが命名です。

今回は、ついやってしまいがちな「意味不明な命名」が、どのようにしてソフトウェアの品質を下げてしまうのか、具体的な例と改善策を見ていきましょう。

ケース1：技術駆動命名 – 何をしているか分からないクラスとメソッド

皆さんのプロジェクトに、このようなクラスはないでしょうか？

【Before】改善前のコード

// ゲームキャラクターのステータスを管理しているつもりのクラス
class GameStateManager {
    private int value01; // おそらくHP

    // 謎の値を変更するメソッド
    public void modifyValue01(int amount) {
        this.value01 -= amount;
        if (this.value01 < 0) {
            this.value01 = 0;
            updateStatusFlag(); // 状態フラグを更新
        }
    }

    private void updateStatusFlag() {
        // ... 何らかの処理
    }
}

GameStateManager、value01、modifyValue01… これらの名前から、このコードが一体何をしているのか正確に理解できるでしょうか？おそらく、クラスの内部を一行ずつ追わなければ、これが「キャラクターのHPを管理し、ダメージを受けてHPが0未満になったら0に補正する処理」だとは分かりません。

このような、データ型や技術的な役割だけで名前をつけてしまうことを技術駆動命名と呼びます。これは、コードの意図を隠し、読む人に余計な解読作業を強いるアンチパターンです。

【After】改善後のコード このコードを、**何を表しているのか（ドメイン）**が分かるように名前を付け直してみましょう。

// プレイヤーキャラクターの状態を管理するクラス
class PlayerCharacter {
    private int hitPoint; // HP

    // ダメージを受けるメソッド
    public void takeDamage(int damageAmount) {
        this.hitPoint -= damageAmount;
        if (this.hitPoint < 0) {
            this.hitPoint = 0;
            checkForDefeat(); // 倒されたかどうかを判定
        }
    }

    private void checkForDefeat() {
        // ... 倒された場合の処理
    }
}

いかがでしょうか。PlayerCharacterがtakeDamage（ダメージを受ける）するとhitPointが減る、というビジネスロジックが一目で分かるようになりました。良い命名は、コード自身に仕様を語らせるのです。

ケース2：連番命名 – 思考停止が生む負の遺産

もう一つの悪い例が連番命名です。

【Before】改善前のコード

class Utility01 {
    public void processData01() { /*...*/ }
    public void processData02() { /*...*/ }
    public void processData03() { /*...*/ }
    // ...延々と続く
}

Utility01、processData02… このような名前は、命名を放棄しているのと同じです。新しいメソッドを追加するとき、processData04を作れば良いのでしょうか？ processData01と02の違いは何でしょうか？このようなコードは、将来的に必ずメンテナンスの大きな妨げとなります。

【After】改善後のコード 連番ではなく、それぞれの役割に応じた名前を付けましょう。

class ReportGenerator {
    // 日次レポートを生成する
    public void generateDailyReport() { /*...*/ }
    // 月次レポートをCSV形式で出力する
    public void exportMonthlyReportAsCsv() { /*...*/ }
    // ユーザー統計を計算する
    public void calculateUserStatistics() { /*...*/ }
}

このように具体的な名前にすることで、各メソッドの責任範囲が明確になり、他の開発者が「どのメソッドを使えば良いのか」と迷うことがなくなります。