コーディングの命名規則完全ガイド｜読みやすい変数名・関数名の付け方と実例

はじめに

コーディングにおける命名規則は、変数名・関数名・クラス名・ファイル名などに一貫した名前を付けるためのルールです。コードは一度書いて終わりではなく、あとから読み返したり、修正したり、他の人が引き継いだりします。そのとき、名前がわかりやすいかどうかで、コードの理解しやすさは大きく変わります。

たとえば、次のような変数名があったとします。

JavaScript
const d = 30;
const u = getData();

これだけでは、d が日数なのか距離なのか、u がユーザーなのかURLなのか判断しにくいです。一方で、次のように書かれていれば意味がすぐに伝わります。

JavaScript
const trialDays = 30;
const user = getUser();

命名規則は、単に「見た目をきれいにするためのルール」ではありません。読みやすく、修正しやすく、バグを生みにくいコードを書くための重要な考え方です。

この記事では、コーディングの命名規則について、初心者にもわかりやすく基本から解説します。代表的な命名ルール、変数名・関数名・クラス名の付け方、言語別の違い、NGパターン、実例による改善例までまとめて紹介します。

1. コーディングの命名規則とは？初心者にもわかる基本

1-1. 命名規則の意味と役割

命名規則とは、コード内で使う名前の付け方を統一するためのルールです。プログラムでは、変数、関数、クラス、ファイル、定数、ディレクトリなど、さまざまなものに名前を付けます。

命名規則を決めておくことで、コード全体に一貫性が生まれます。

たとえば、ユーザー名を表す変数をある場所では userName、別の場所では user_name、さらに別の場所では username と書いていると、同じ意味なのか別の意味なのか判断しにくくなります。

命名規則は、こうした表記ゆれを防ぎ、誰が読んでも理解しやすいコードにするためのものです。

1-2. 変数名・関数名・クラス名など「識別子」との関係

プログラミングでは、変数名や関数名、クラス名などをまとめて「識別子」と呼びます。識別子は、プログラム内の値や処理、部品を区別するための名前です。

たとえば、次のコードでは userName、getUserName、User が識別子です。

JavaScript
const userName = "Tanaka";

function getUserName() {
  return userName;
}

class User {
  constructor(name) {
    this.name = name;
  }
}

識別子の名前がわかりやすいと、コードを読む人は「この変数は何を表すのか」「この関数は何をするのか」をすぐに理解できます。逆に、識別子の名前が曖昧だと、処理内容を細かく追わないと意味がわかりません。

1-3. コーディング規約との違い

命名規則とよく似た言葉に「コーディング規約」があります。

命名規則は、名前の付け方に関するルールです。一方、コーディング規約は、コード全体の書き方に関するルールです。

たとえば、コーディング規約には次のような内容が含まれます。

• インデントはスペース2つにする

• 1行の文字数は何文字までにする

• 関数の書き方を統一する

• コメントの書き方を決める

• 変数名はキャメルケースにする

このうち、「変数名はキャメルケースにする」のような名前に関するルールが命名規則です。つまり、命名規則はコーディング規約の一部と考えるとわかりやすいでしょう。

1-4. 命名規則がないコードで起こる問題

命名規則がないコードでは、次のような問題が起こりやすくなります。

まず、同じ意味の名前が複数の書き方で登場します。

JavaScript
const userName = "Sato";
const user_name = "Sato";
const username = "Sato";

このようなコードでは、それぞれが同じ意味なのか、微妙に違う意味なのか判断しにくくなります。

また、意味のない名前が増えることもあります。

JavaScript
const a = 1000;
const b = 0.1;
const c = a * b;

これでは、a、b、c が何を表しているのか読み手に伝わりません。次のように命名すれば、処理内容が明確になります。

JavaScript
const price = 1000;
const taxRate = 0.1;
const taxAmount = price * taxRate;

命名規則がないコードは、最初は早く書けるように見えても、あとから読む時間や修正する時間が増えてしまいます。

2. 命名規則が重要な理由

2-1. コードの可読性が上がる

命名規則を守る最大のメリットは、コードの可読性が上がることです。可読性とは、コードの読みやすさのことです。

良い名前は、それ自体が説明になります。

JavaScript
const isLoggedIn = true;
const totalPrice = 5000;
const activeUsers = [];

このような名前であれば、コメントがなくても意味を理解できます。コードは書く時間よりも読む時間のほうが長いと言われることがあります。読みやすい名前を付けることは、開発効率に直結します。

2-2. 保守・改修しやすくなる

システムはリリース後も修正や機能追加が行われます。そのとき、名前がわかりやすいコードは保守しやすくなります。

たとえば、calculateDiscountPrice という関数名であれば、割引後の価格を計算する関数だとわかります。一方、calc だけでは何を計算しているのかわかりません。

保守や改修では、既存コードの意図を素早く理解することが重要です。命名規則が整っていると、コードの構造や役割を把握しやすくなります。

2-3. チーム開発で認識のズレを防げる

チーム開発では、複数人が同じコードベースを触ります。そのため、人によって名前の付け方がバラバラだと、認識のズレが起こりやすくなります。

たとえば、「ユーザー一覧」を表す名前が、ある人は userList、別の人は users、さらに別の人は userArray と書いていると、統一感がなくなります。

チームで命名規則を決めておけば、「配列は複数形にする」「取得処理は get から始める」などの共通認識を持てます。これにより、レビューや実装時の迷いが減ります。

2-4. バグやレビュー指摘を減らせる

名前と処理内容が一致していないと、誤解によるバグが起こりやすくなります。

たとえば、getUser という関数がデータ取得だけでなく、データ更新まで行っていた場合、呼び出し側は副作用があることに気づきにくいです。

JavaScript
function getUser() {
  updateLastAccessedAt();
  return user;
}

この場合、getUserAndUpdateLastAccessedAt のように副作用がわかる名前にするか、処理を分けるべきです。

命名が適切であれば、コードレビューで「この名前だと意味が伝わりにくい」「処理内容と名前が合っていない」といった指摘も減らせます。

2-5. 未来の自分が読み返しやすくなる

命名規則は、チームのためだけでなく未来の自分のためにも重要です。書いた直後は理解できるコードでも、数週間後や数か月後に読み返すと、意図を忘れていることがあります。

そのとき、x、tmp、data のような曖昧な名前ばかりだと、処理を一から読み直さなければなりません。

一方で、expiredSubscriptionUsers や calculateMonthlyRevenue のように意味が明確な名前であれば、過去の自分が何を意図していたのか思い出しやすくなります。

3. 代表的な命名規則の種類と使い分け

3-1. キャメルケース：camelCase

キャメルケースは、最初の単語を小文字で始め、2語目以降の先頭を大文字にする書き方です。

JavaScript
userName
totalPrice
isLoggedIn
createdAt

JavaScriptやTypeScriptでは、変数名や関数名によく使われます。

JavaScript
const userName = "Tanaka";

function getUserName() {
  return userName;
}

単語の区切りがわかりやすく、コード内でも読みやすい命名規則です。

3-2. パスカルケース：PascalCase

パスカルケースは、すべての単語の先頭を大文字にする書き方です。

JavaScript
UserName
TotalPrice
UserProfile
PaymentService

クラス名やコンポーネント名によく使われます。

JavaScript
class UserProfile {
  constructor(name) {
    this.name = name;
  }
}

JavaScript、TypeScript、Java、C#などでは、クラス名にパスカルケースを使うことが多いです。

3-3. スネークケース：snake_case

スネークケースは、単語をアンダースコア _ でつなぐ書き方です。

Python
実行する
user_name
total_price
is_logged_in
created_at

Pythonでは、変数名や関数名にスネークケースを使うのが一般的です。

Python
実行する
user_name = "Tanaka"

def get_user_name():
    return user_name

データベースのカラム名でもよく使われます。

SQL
user_id
created_at
updated_at

3-4. ケバブケース：kebab-case

ケバブケースは、単語をハイフン - でつなぐ書き方です。

user-name
total-price
main-header
login-button

多くのプログラミング言語では、変数名にハイフンを使えません。そのため、ケバブケースは主にHTML、CSS、URL、ファイル名などで使われます。

HTML
<div class="user-profile">
  <button class="login-button">Login</button>
</div>

CSSのクラス名やURLのパスでは、ケバブケースが読みやすく扱いやすいです。

3-5. コンスタントケース：CONSTANT_CASE

コンスタントケースは、すべて大文字で書き、単語をアンダースコアで区切る書き方です。

JavaScript
MAX_RETRY_COUNT
API_BASE_URL
DEFAULT_TIMEOUT
TAX_RATE

主に定数名に使われます。

JavaScript
const MAX_RETRY_COUNT = 3;
const API_BASE_URL = "https://example.com";

変更されない値、設定値、環境変数などに使うと、通常の変数と区別しやすくなります。

3-6. ハンガリアン記法とは

ハンガリアン記法は、変数名の先頭に型や意味を表す接頭辞を付ける命名方法です。

strName
intCount
boolIsActive

たとえば、strName は文字列、intCount は整数、boolIsActive は真偽値を表すといったルールです。

昔の開発環境では型情報がわかりにくかったため使われることがありました。しかし、現代の多くの言語やエディタでは型推論や補完機能が充実しているため、過度なハンガリアン記法は避けられる傾向があります。

ただし、UI要素などで意味を明確にするために、限定的に接頭辞を使うケースはあります。

JavaScript
const inputEmail = document.querySelector("#email");
const buttonSubmit = document.querySelector("#submit");

重要なのは、チームやプロジェクトのルールに合わせることです。

3-7. 命名規則ごとの使用例一覧

命名規則は、どれか1つだけを使うものではありません。変数、関数、クラス、定数、ファイルなど、対象に応じて使い分けることが大切です。

4. 読みやすい変数名の付け方

4-1. 変数の役割が一目でわかる名前にする

変数名は、その値が何を表しているのか一目でわかる名前にしましょう。

悪い例です。

JavaScript
const n = "Tanaka";
const p = 3000;

改善例です。

JavaScript
const userName = "Tanaka";
const productPrice = 3000;

短い名前は入力が楽ですが、意味が伝わらなければ読み手の負担が増えます。変数名は、多少長くなっても役割が明確なほうがよいです。

4-2. 抽象的すぎる名前を避ける

data、info、value、item のような名前は便利ですが、抽象的すぎる場合があります。

JavaScript
const data = await fetchUsers();

この場合、取得しているのがユーザー一覧なら、次のように書くほうが明確です。

JavaScript
const users = await fetchUsers();

ただし、ループ内の短い範囲であれば item を使っても問題ない場合があります。

JavaScript
items.forEach((item) => {
  console.log(item.name);
});

大切なのは、スコープの広さに応じて適切な具体性を持たせることです。

4-3. 省略しすぎない

省略しすぎた名前は、意味が伝わりにくくなります。

JavaScript
const usr = getUser();
const msg = "Hello";
const cnt = 10;

一般的に広く理解される略語であれば問題ありませんが、独自の省略は避けたほうが安全です。

JavaScript
const user = getUser();
const message = "Hello";
const count = 10;

特にチーム開発では、自分だけがわかる略語は使わないようにしましょう。

4-4. 単数形・複数形を正しく使い分ける

変数が1つの値を表すのか、複数の値を表すのかは、名前で区別できるようにします。

JavaScript
const user = { id: 1, name: "Tanaka" };
const users = [
  { id: 1, name: "Tanaka" },
  { id: 2, name: "Sato" },
];

配列やリストには複数形を使うのが基本です。userList のように書くこともありますが、単にユーザーの配列であれば users のほうが簡潔です。

4-5. 真偽値はis・has・canなどで始める

真偽値を表す変数は、is、has、can、should などで始めると意味が伝わりやすくなります。

JavaScript
const isLoggedIn = true;
const hasPermission = false;
const canEdit = true;
const shouldShowModal = false;

それぞれの使い分けは次のとおりです。

真偽値の名前は、読んだときに「はい／いいえ」で答えられる形にするとわかりやすくなります。

4-6. 配列・リスト・コレクションの命名例

配列やリストは、複数形を基本にします。

JavaScript
const users = [];
const products = [];
const orderItems = [];
const errorMessages = [];

「一覧」であることを強調したい場合は、List を付けても構いません。

JavaScript
const userList = [];
const productList = [];

ただし、プロジェクト内で users と userList が混在すると表記ゆれになります。チームでどちらを使うか決めておくとよいでしょう。

4-7. 良い変数名と悪い変数名の実例

変数名は、コードを読む人へのメッセージです。名前だけで意味が伝わるかを意識しましょう。

5. 読みやすい関数名・メソッド名の付け方

5-1. 関数名は「何をするか」がわかる動詞から始める

関数名は、処理を表すため、動詞から始めるのが基本です。

JavaScript
getUser()
createOrder()
updateProfile()
deleteComment()
calculateTotalPrice()

関数名を見たときに、「何をする関数なのか」がわかることが重要です。

悪い例です。

JavaScript
function user() {}
function total() {}
function process() {}

改善例です。

JavaScript
function getUser() {}
function calculateTotalPrice() {}
function processPayment() {}

名詞だけでは処理内容が伝わりにくいため、動詞と対象を組み合わせるとわかりやすくなります。

5-2. get・set・create・update・deleteの使い分け

関数名でよく使う動詞には、それぞれ意味があります。

get と fetch は似ていますが、プロジェクトによって使い分けることがあります。たとえば、メモリ上の値を取得する場合は get、APIやデータベースから取得する場合は fetch とするルールです。

JavaScript
const userName = getUserName();
const users = await fetchUsers();

5-3. 戻り値が真偽値の関数名の付け方

戻り値が true または false の関数は、真偽値の変数と同じように is、has、can などを使うとわかりやすくなります。

JavaScript
function isValidEmail(email) {
  return email.includes("@");
}

function hasPermission(user) {
  return user.role === "admin";
}

function canEditPost(user, post) {
  return user.id === post.authorId;
}

呼び出し側でも自然に読めます。

JavaScript
if (isValidEmail(email)) {
  submitForm();
}

checkEmail のような名前でも意味は伝わりますが、戻り値が真偽値なのか、エラーを投げるのか、別の結果を返すのかが曖昧です。

5-4. 副作用のある関数名は明確にする

副作用とは、関数の外部に影響を与える処理のことです。たとえば、データベースを更新する、ファイルを書き込む、画面表示を変更する、通知を送るなどが副作用にあたります。

副作用がある関数は、名前でそれがわかるようにしましょう。

悪い例です。

JavaScript
function getUser() {
  updateLastLoginAt();
  return user;
}

getUser という名前からは、取得するだけの関数に見えます。しかし実際には更新処理も行っています。

改善例です。

JavaScript
function getUserAndUpdateLastLoginAt() {
  updateLastLoginAt();
  return user;
}

または、処理を分けます。

JavaScript
const user = getUser();
updateLastLoginAt(user.id);

関数名と処理内容が一致していると、意図しない副作用によるバグを防ぎやすくなります。

5-5. 長すぎる関数名を避けるコツ

関数名はわかりやすさが大切ですが、長すぎると読みづらくなります。

JavaScript
function getUserListFilteredByActiveStatusAndSortedByCreatedDate() {}

このような名前は情報量が多すぎます。処理を分割できないか考えましょう。

JavaScript
function getActiveUsers() {}
function sortUsersByCreatedDate(users) {}

長い名前が必要になる場合、その関数が多くの責務を持ちすぎている可能性があります。関数名に多くの条件を詰め込む前に、処理を分けられないか確認しましょう。

5-6. 良い関数名と悪い関数名の実例

関数名は「動詞 + 対象」を基本にすると、読みやすくなります。

6. クラス名・ファイル名・定数名の命名規則

6-1. クラス名は名詞・概念名で付ける

クラス名は、オブジェクトや概念を表すため、名詞で付けるのが基本です。

JavaScript
class User {}
class Order {}
class PaymentService {}
class UserRepository {}

関数名は動詞から始めますが、クラス名は「何であるか」を表します。そのため、CreateUser のような動詞から始まる名前は、クラス名としては不自然な場合があります。

ただし、処理を担当するクラスであれば、UserCreator や PaymentProcessor のように役割を表す名詞にすると自然です。

6-2. ファイル名とクラス名を対応させる

クラスを1ファイルに1つ定義する場合、ファイル名とクラス名を対応させると探しやすくなります。

UserProfile.ts
UserProfile.jsx
PaymentService.java
OrderRepository.php

たとえば、UserProfile クラスを探したいときに、ファイル名も UserProfile.ts であればすぐに見つけられます。

一方、ファイル名が common.ts や utils.ts ばかりになると、どこに何があるのかわかりにくくなります。

6-3. 定数名は大文字スネークケースで書く

定数名は、大文字のスネークケースで書くことが多いです。

JavaScript
const MAX_LOGIN_ATTEMPTS = 5;
const DEFAULT_LANGUAGE = "ja";
const API_BASE_URL = "https://example.com";

ただし、言語やプロジェクトによっては、すべての const を大文字にするのではなく、「本当に定数として扱う設定値」だけを大文字にする場合もあります。

JavaScript
const userName = "Tanaka";
const MAX_RETRY_COUNT = 3;

userName は再代入されないだけで通常の値、MAX_RETRY_COUNT は設定値としての定数、という使い分けです。

6-4. モジュール名・パッケージ名の考え方

モジュール名やパッケージ名は、役割や機能単位がわかる名前にします。

auth
users
orders
payments
notifications

抽象的な common、misc、lib などは便利ですが、何でも入れられる場所になりやすいため注意が必要です。

たとえば、認証関連の処理であれば auth、決済関連であれば payments のように、責務ごとに分けると構造がわかりやすくなります。

6-5. ディレクトリ名の付け方

ディレクトリ名は、プロジェクト全体の見通しに影響します。名前を見ただけで、中に何が入っているか想像できるようにしましょう。

components
pages
hooks
services
repositories
utils
types

フロントエンドでは components、pages、hooks などがよく使われます。バックエンドでは controllers、services、models、repositories などが使われます。

ディレクトリ名も、単数形と複数形、ケバブケースとスネークケースなどが混在しないように統一することが重要です。

7. 言語別の命名規則の違い

7-1. JavaScript・TypeScriptの命名規則

JavaScriptやTypeScriptでは、一般的に次のような命名規則が使われます。

TypeScript
const userName = "Tanaka";

function getUserName() {
  return userName;
}

class UserProfile {}

const MAX_RETRY_COUNT = 3;

変数名・関数名はキャメルケース、クラス名や型名はパスカルケース、定数名はコンスタントケースを使うことが多いです。

Reactのコンポーネント名も、通常はパスカルケースで書きます。

TypeScript
function UserProfile() {
  return <div>User Profile</div>;
}

7-2. Pythonの命名規則

Pythonでは、変数名や関数名にスネークケースを使うのが一般的です。

Python
実行する
user_name = "Tanaka"

def get_user_name():
    return user_name

class UserProfile:
    pass

MAX_RETRY_COUNT = 3

クラス名はパスカルケース、定数名は大文字スネークケースがよく使われます。

Pythonでは、命名規則が読みやすさに大きく影響します。言語の慣習に合わせることで、他のPython開発者にも読みやすいコードになります。

7-3. Javaの命名規則

Javaでは、クラス名はパスカルケース、変数名やメソッド名はキャメルケースで書くのが一般的です。

Java
public class UserProfile {
    private String userName;

    public String getUserName() {
        return userName;
    }
}

定数は大文字スネークケースを使います。

Java
public static final int MAX_RETRY_COUNT = 3;

Javaでは、クラス名とファイル名を一致させる必要があるため、命名の一貫性が特に重要です。

7-4. PHPの命名規則

PHPでは、プロジェクトやフレームワークによって違いがありますが、クラス名はパスカルケース、メソッド名はキャメルケースがよく使われます。

PHP
class UserProfile
{
    public function getUserName()
    {
        return $this->userName;
    }
}

変数名はキャメルケースが使われることもあれば、スネークケースが使われることもあります。

PHP
$userName = "Tanaka";
$user_name = "Tanaka";

Laravelなどのフレームワークでは、フレームワークの慣習に合わせることが大切です。

7-5. Rubyの命名規則

Rubyでは、変数名やメソッド名にスネークケースを使うのが一般的です。

Ruby
user_name = "Tanaka"

def get_user_name
  user_name
end

class UserProfile
end

クラス名やモジュール名はパスカルケース、定数は大文字で始めます。

Ruby
MAX_RETRY_COUNT = 3

Rubyでは、自然に読めるメソッド名が好まれる傾向があります。

7-6. C#の命名規則

C#では、クラス名、メソッド名、プロパティ名にパスカルケースを使うことが多いです。

C#
public class UserProfile
{
    public string UserName { get; set; }

    public string GetUserName()
    {
        return UserName;
    }
}

ローカル変数や引数にはキャメルケースを使います。

C#
var userName = "Tanaka";

C#では、言語やフレームワークの標準的な命名に合わせることで、読みやすく統一されたコードになります。

7-7. 言語ごとの命名規則比較表

命名規則は言語によって違います。自分の好みだけで決めるのではなく、使用する言語やフレームワークの慣習に合わせることが重要です。

8. 命名で避けるべきNGパターン

8-1. a・b・tmpなど意味が伝わらない名前

a、b、x、tmp のような名前は、意味が伝わりにくいため避けましょう。

JavaScript
const a = 100;
const b = 200;
const tmp = a + b;

改善例です。

JavaScript
const basePrice = 100;
const shippingFee = 200;
const totalPrice = basePrice + shippingFee;

ただし、短いループや数学的な処理では、i や x が許容される場合もあります。

JavaScript
for (let i = 0; i < users.length; i++) {
  console.log(users[i]);
}

短い名前を使う場合は、スコープが狭く、意味が明らかな場合に限定しましょう。

8-2. data・info・valueなど曖昧な名前

data、info、value は使いやすい反面、何を表しているのか曖昧になりがちです。

JavaScript
const data = await fetch("/api/users");

改善例です。

JavaScript
const usersResponse = await fetch("/api/users");
const users = await usersResponse.json();

具体的な名前を付けることで、読み手が中身を推測しやすくなります。

8-3. 日本語ローマ字の多用

日本語をローマ字にした名前は、日本語話者にはわかりやすい場合もありますが、英語のコードと混ざると読みにくくなることがあります。

JavaScript
const shohinKakaku = 1000;
const zeikomiKingaku = 1100;

改善例です。

JavaScript
const productPrice = 1000;
const taxIncludedPrice = 1100;

チーム全員が日本語話者で、ドメイン用語として必要な場合を除き、基本的には英語で命名するほうが無難です。

8-4. 否定形の真偽値

否定形の真偽値は、条件分岐で読みにくくなることがあります。

JavaScript
const isNotDeleted = true;

if (!isNotDeleted) {
  // 読みにくい
}

改善例です。

JavaScript
const isDeleted = false;

if (isDeleted) {
  // 削除済みの場合
}

二重否定になる名前は避け、肯定形で表せないか考えましょう。

8-5. 表記ゆれや似た名前の混在

同じ意味の名前が複数の書き方で登場すると、混乱の原因になります。

JavaScript
const userId = 1;
const userID = 1;
const uid = 1;

プロジェクト内では、Id と ID のどちらを使うか、userId と uid のどちらを使うかを統一しましょう。

似た名前も注意が必要です。

JavaScript
const user = {};
const users = [];
const userData = {};
const userInfo = {};

それぞれの違いが明確でない場合、命名を見直すべきです。

8-6. 名前と処理内容が一致していないケース

名前と処理内容が一致していないと、バグの原因になります。

JavaScript
function getUser() {
  deleteExpiredUsers();
  return user;
}

この関数名からは、ユーザーを取得するだけに見えます。しかし実際には削除処理も含まれています。

改善例です。

JavaScript
function deleteExpiredUsersAndGetUser() {
  deleteExpiredUsers();
  return user;
}

ただし、このように名前が長くなる場合は、処理を分けるほうがよいことも多いです。

8-7. 略語・専門用語を使いすぎるケース

略語や専門用語は、チーム内で共通理解がある場合には便利です。しかし、使いすぎると新しいメンバーが理解しにくくなります。

JavaScript
const usrCnt = 10;
const pymtStat = "paid";

改善例です。

JavaScript
const userCount = 10;
const paymentStatus = "paid";

一般的な略語以外は、できるだけ省略せずに書くことをおすすめします。

9. 実例で学ぶ命名改善パターン

9-1. 悪い変数名を読みやすく改善する例

悪い例です。

JavaScript
const d = "2026-01-01";
const n = 5;
const r = true;

改善例です。

JavaScript
const startDate = "2026-01-01";
const retryCount = 5;
const isRetryEnabled = true;

変数名を変えるだけで、コードの意味が大きく伝わりやすくなります。

9-2. 悪い関数名を読みやすく改善する例

悪い例です。

JavaScript
function handle(data) {
  // 注文を作成する
}

改善例です。

JavaScript
function createOrder(orderInput) {
  // 注文を作成する
}

handle は何でも表せるため、具体性が足りません。何を処理するのかを関数名に含めましょう。

9-3. Boolean変数の改善例

悪い例です。

JavaScript
const login = true;
const permission = false;
const error = true;

改善例です。

JavaScript
const isLoggedIn = true;
const hasPermission = false;
const hasError = true;

真偽値は、状態や条件がわかる名前にすると条件分岐が読みやすくなります。

JavaScript
if (hasPermission) {
  showAdminMenu();
}

9-4. 配列・オブジェクトの改善例

悪い例です。

JavaScript
const user = [
  { id: 1, name: "Tanaka" },
  { id: 2, name: "Sato" },
];

配列なのに単数形の user だと、1人のユーザーなのか複数のユーザーなのかわかりにくいです。

改善例です。

JavaScript
const users = [
  { id: 1, name: "Tanaka" },
  { id: 2, name: "Sato" },
];

オブジェクトの場合は単数形にします。

JavaScript
const user = { id: 1, name: "Tanaka" };

9-5. 長すぎる名前を適切に短くする例

長すぎる名前の例です。

JavaScript
const usersWhoHaveNotLoggedInForMoreThanThirtyDays = [];

意味は明確ですが、やや長すぎます。文脈に応じて短くできます。

JavaScript
const inactiveUsers = [];

ただし、inactiveUsers の定義が「30日以上ログインしていないユーザー」だとわからない場合は、コメントや関数名で補足します。

JavaScript
const inactiveUsers = getUsersInactiveForDays(30);

名前を短くする場合は、意味が失われない範囲で行いましょう。

9-6. コードレビューで指摘されやすい命名例

コードレビューで指摘されやすい命名には、次のようなものがあります。

レビューで命名を指摘されることは悪いことではありません。より読みやすいコードにするための改善ポイントとして捉えましょう。

10. チーム開発で命名規則を統一する方法

10-1. プロジェクトの命名ルールをドキュメント化する

チームで命名規則を統一するには、ルールをドキュメント化することが重要です。

たとえば、次のような内容をまとめます。

- 変数名はcamelCaseを使う
- クラス名はPascalCaseを使う
- 定数名はCONSTANT_CASEを使う
- Boolean変数はis / has / can / shouldで始める
- 配列は原則として複数形にする
- API取得関数はfetchで始める

ドキュメントがあると、新しいメンバーもプロジェクトのルールを理解しやすくなります。

10-2. 既存コードのルールに合わせる

新しくコードを書くときは、自分の好みよりも既存コードのルールを優先しましょう。

既存コードがスネークケースで統一されているのに、新しくキャメルケースを混ぜると、コード全体の一貫性が崩れます。

完璧な命名規則でなくても、プロジェクト内で統一されていることは大きな価値があります。改善したい場合は、個別に混ぜるのではなく、チームで方針を決めてまとめて変更するのが安全です。

10-3. Linter・Formatterを活用する

命名規則の一部は、LinterやFormatterで自動チェックできます。

JavaScriptやTypeScriptであればESLint、PythonであればRuffやflake8、PHPであればPHP_CodeSnifferなどが使われます。

Linterを導入すると、命名ルール違反を自動で検出できます。

- 変数名の形式がルールに合っているか
- 未使用の変数がないか
- 定数名が大文字になっているか

人間のレビューだけに頼ると見落としが発生します。自動化できる部分はツールに任せると効率的です。

10-4. コードレビューで命名を確認する

Linterでチェックできない命名の良し悪しは、コードレビューで確認します。

たとえば、次のような観点で見ます。

• 名前から役割が伝わるか

• 処理内容と名前が一致しているか

• 抽象的すぎないか

• 既存コードと表記が揃っているか

• 長すぎたり短すぎたりしないか

命名は正解が1つとは限りません。そのため、レビューでは「なぜその名前がよいのか」を説明できることが大切です。

10-5. 命名に迷ったときの判断基準を決める

チームで命名に迷ったときの判断基準を決めておくと、議論がスムーズになります。

たとえば、次のような基準です。

1. 既存コードの命名に合わせる
2. 言語やフレームワークの慣習に合わせる
3. 省略よりも明確さを優先する
4. Booleanは肯定形で書く
5. 意味が広すぎる名前は避ける

判断基準があると、個人の好みではなく、チームとして一貫した命名ができます。

11. 命名に迷ったときの考え方

11-1. 何を表す名前なのかを日本語で整理する

命名に迷ったら、まず日本語で「これは何を表すものか」を整理しましょう。

たとえば、「30日以上ログインしていないユーザーの一覧」であれば、次のように分解できます。

対象：ユーザー
条件：30日以上ログインしていない
形式：一覧

これを英語にすると、次のような候補が考えられます。

JavaScript
inactiveUsers
usersInactiveFor30Days

いきなり英語で考えるよりも、日本語で役割を整理してから英語にすると、適切な名前を付けやすくなります。

11-2. 役割・対象・条件を分解する

名前は、役割・対象・条件に分けて考えると整理しやすくなります。

たとえば、getActiveUsers は次のように分解できます。

役割：get
対象：Users
条件：Active

calculateTotalPrice なら次のようになります。

役割：calculate
対象：Price
条件：Total

関数名は「動詞 + 対象 + 条件」、変数名は「条件 + 対象」を意識すると、自然な名前になりやすいです。

11-3. 英語の品詞を意識する

命名では、英語の品詞を意識すると読みやすくなります。

変数名やクラス名は名詞を使います。

JavaScript
user
order
paymentStatus
UserProfile

関数名は動詞から始めます。

JavaScript
getUser
createOrder
validateEmail

真偽値は形容詞や状態を表す形にします。

JavaScript
isActive
hasError
canSubmit

品詞が揃っていると、コードが自然な英文のように読めます。

11-4. よく使う英単語・動詞をストックする

命名でよく使う英単語を覚えておくと、迷う時間を減らせます。

よく使う単語をチームで共有しておくと、命名のブレを減らせます。

11-5. 翻訳ツール・命名支援ツールの使い方

英語の命名に迷ったときは、翻訳ツールやAIを使うのも有効です。ただし、出てきた候補をそのまま使うのではなく、コードの文脈に合っているか確認しましょう。

たとえば、「有効期限切れのユーザー」を翻訳すると、expired user のような候補が出る場合があります。しかし、複数のユーザー一覧であれば expiredUsers、サブスクリプションが切れたユーザーであれば usersWithExpiredSubscription のほうが具体的です。

命名支援ツールは便利ですが、最終的には人間が文脈を見て判断することが大切です。

12. 命名規則チェックリスト

12-1. 役割が一目で伝わるか

名前を見ただけで、その変数や関数の役割がわかるか確認しましょう。

JavaScript
const result = calculateTotalPrice(items);

result だけでは抽象的です。

JavaScript
const totalPrice = calculateTotalPrice(items);

このように、結果の中身がわかる名前にすると読みやすくなります。

12-2. チームのルールに合っているか

どれだけ良い名前でも、チームの命名規則から外れていると混乱の原因になります。

たとえば、プロジェクトで変数名をキャメルケースに統一しているなら、user_name ではなく userName を使うべきです。

命名は個人の好みではなく、プロジェクト全体の一貫性を優先しましょう。

12-3. 表記ゆれがないか

同じ意味の言葉が複数の表記で使われていないか確認します。

userId
userID
uid

このような表記ゆれがあると、検索もしづらくなります。プロジェクト内で使う単語を統一しましょう。

12-4. 長すぎず短すぎないか

名前は短すぎても長すぎても読みにくくなります。

短すぎる例です。

JavaScript
const c = 10;

長すぎる例です。

JavaScript
const numberOfUsersWhoCanAccessAdminDashboard = 10;

改善例です。

JavaScript
const adminUserCount = 10;

必要な情報を残しつつ、簡潔にすることが大切です。

12-5. 名前と処理内容が一致しているか

関数名と処理内容が一致しているか確認しましょう。

JavaScript
function getUser() {
  saveAccessLog();
  return user;
}

この関数は取得だけでなくログ保存も行っています。副作用があるなら名前に含めるか、処理を分ける必要があります。

12-6. 将来変更されても意味が破綻しないか

名前が特定の条件に依存しすぎていると、将来の変更で意味が合わなくなることがあります。

JavaScript
const usersUnder20 = [];

もし条件が「20歳未満」から「未成年」に変わった場合、この名前は不正確になる可能性があります。

JavaScript
const minorUsers = [];

ビジネス上の意味に基づいた名前にすると、将来の変更にも強くなります。

13. コーディングの命名規則に関するよくある質問

13-1. 変数名は英語で書くべき？

基本的には英語で書くことをおすすめします。多くのプログラミング言語、ライブラリ、フレームワークは英語を前提としているため、英語の変数名のほうが自然に読みやすくなります。

ただし、業務ドメイン特有の言葉で、日本語のほうが正確に意味を表せる場合もあります。その場合でも、チームで合意したうえで使うことが大切です。

13-2. 変数名は長くてもいい？

長くても、意味が明確であれば問題ありません。ただし、長すぎる名前は読みづらくなります。

目安としては、名前を読んだときに自然に意味が伝わり、かつ冗長でないことが重要です。

JavaScript
const activeUsers = [];
const usersWithExpiredSubscription = [];

この程度であれば、十分に読みやすい名前です。

13-3. 日本語の変数名は使ってもいい？

技術的には、日本語の変数名を使える言語もあります。

JavaScript
const ユーザー名 = "Tanaka";

しかし、チーム開発やライブラリとの整合性、入力のしやすさを考えると、基本的には英語の命名をおすすめします。

日本語を使う場合は、プロジェクト内で明確なルールを決めておきましょう。

13-4. 命名規則はどこまで厳密に守るべき？

命名規則は、コードの読みやすさを高めるためのものです。そのため、厳密に守ること自体が目的になってはいけません。

ただし、チーム開発では一貫性が重要です。基本ルールは守りつつ、例外が必要な場合は理由を説明できるようにしておきましょう。

13-5. 個人開発でも命名規則は必要？

個人開発でも命名規則は必要です。なぜなら、未来の自分がコードを読み返すからです。

書いた直後は理解できても、時間が経つと細かい意図を忘れてしまいます。命名規則を意識しておくと、後から修正や機能追加をするときに楽になります。

小さな個人開発でも、最低限次のルールは決めておくとよいでしょう。

- 変数名は役割がわかる名前にする
- Booleanはis / has / canで始める
- 配列は複数形にする
- 関数名は動詞から始める
- 表記ゆれを避ける

13-6. AIに命名を任せてもいい？

AIに命名候補を出してもらうのは有効です。特に、英語表現に迷ったときや、複数の候補を比較したいときに役立ちます。

ただし、AIが出した名前をそのまま使うのではなく、次の点を確認しましょう。

- プロジェクトの命名規則に合っているか
- 処理内容と一致しているか
- 抽象的すぎないか
- 長すぎないか
- チームメンバーが理解しやすいか

AIは命名の補助には便利ですが、最終判断はコードの文脈を理解している開発者が行うべきです。

まとめ

コーディングの命名規則は、読みやすく保守しやすいコードを書くために欠かせないルールです。変数名、関数名、クラス名、ファイル名、定数名などの名前を適切に付けることで、コードの意図が伝わりやすくなり、チーム開発でも認識のズレを防げます。

命名で大切なのは、単にキャメルケースやスネークケースを覚えることだけではありません。名前を見ただけで役割がわかるか、処理内容と一致しているか、表記ゆれがないか、将来読み返しても理解できるかを意識することです。

特に、変数名は「何を表すか」、関数名は「何をするか」、クラス名は「何であるか」が伝わるように付けると、自然で読みやすいコードになります。

命名に迷ったときは、まず日本語で役割を整理し、対象・条件・処理を分解してから英語にすると考えやすくなります。チーム開発では、命名規則をドキュメント化し、Linterやコードレビューを活用して一貫性を保ちましょう。

良い命名は、コードの品質を大きく高めます。今日から変数名や関数名を少し丁寧に見直すだけでも、読みやすいコードに近づけることができます。