記事の目的
Web開発をしていると、
「キャメルケース(camelCase)とスネークケース(snake_case)、どっちを使えばいいの?」
という疑問に必ずぶつかります。
↓
特に Laravel × Vue.js(SPA構成) のように
バックエンドとフロントエンドが混ざる開発では、命名の統一はとても大切です。
↓
この記事では、JavaScriptとPHP(Laravel準拠) の命名規則を比較しながら、
実務的な最適解を整理します。
最適な使い分け早見表
| 用途 | JavaScript | PHP(Laravel準拠) | 備考 |
|---|---|---|---|
| 変数名 | 🟩 camelCase | 🐍 snake_case | 言語文化の違いによる |
| 関数・メソッド名 | 🟩 camelCase | 🟩 camelCase | 共通化しやすい部分 |
| クラス名 | 🟦 PascalCase | 🟦 PascalCase | PSR-1準拠、共通OK |
| 定数 | 🟥 UPPER_SNAKE_CASE | 🟥 UPPER_SNAKE_CASE | 共通OK |
| ファイル名 | camelCase or kebab-case | PascalCase(クラス名と一致) | LaravelはPSR規約準拠 |
| DBテーブル名 | - | 🐍 snake_case(複数形) | 例:users, order_items
|
| カラム名 | - | 🐍 snake_case | 例:created_at, user_id
|
| API通信時のキー | 🐍 snake_case | 🐍 snake_case | JSONで統一されることが多い |
| Vue側での扱い | 🟩 camelCase | - | 受け取ったデータをJS風に変換することも多い |
JavaScriptの最適解:camelCase文化
JavaScriptでは、変数名・関数名はcamelCase が基本ルールです。
これはJavaの命名文化を引き継いだもので、読みやすくスッキリした印象になります。
例:
// ✅ 基本ルール
let totalPrice = 1000;
function calculateTax(amount) {
return amount * 0.1;
}
// ✅ クラス名はPascalCase
class UserProfile {
constructor(name) {
this.userName = name;
}
}
// ✅ 定数はUPPER_SNAKE_CASE
const API_URL = "https://example.com/api";
APIレスポンスではsnake_caseが混ざる
LaravelやRailsなど、サーバー側の多くはsnake_caseを採用しているため、
APIレスポンスではこうなります:
{
"user_id": 1,
"created_at": "2025-11-11T00:00:00Z"
}
これをJavaScript側では次のように扱うのが自然です👇
const userId = data.user_id;
const createdAt = data.created_at;
つまり、通信ではsnake_case、内部処理ではcamelCase が最も一般的です。
PHP(Laravel)の最適解:snake_case文化
PHPはC言語文化をルーツに持つため、
変数・プロパティはsnake_case が基本です。
ただし、モダンPHP(Laravelなど)では メソッド名だけcamelCase に寄せています。
例:
<?php
class UserController extends Controller
{
public function getUserInfo(Request $request)
{
$user_id = $request->input('user_id');
$user = User::find($user_id);
$total_price = $user->orders->sum('total_price');
return response()->json([
'user_id' => $user_id,
'total_price' => $total_price,
]);
}
}
ポイント
▫️ $user_id, $total_price → snake_case
▫️ getUserInfo() → camelCase
▫️ UserController → PascalCase
▫️ JSONキー → snake_case(API通信の慣例)
Laravel × Vue.js(SPA構成)の実務的な使い分け
| 層 | 命名規則 | 例 |
|---|---|---|
| Laravel(サーバー側) | snake_case |
user_id, created_at
|
| Vue.js(クライアント側) | camelCase |
userId, createdAt
|
フロントでAPIデータを扱う時、
snake_case → camelCase へ変換するのが読みやすく保守的にも有利です。
変換の一例(axios利用)
// APIレスポンス例
{
user_id: 1,
created_at: "2025-11-11"
}
// Vue側でcamelCaseに変換して扱う
const formatted = {
userId: data.user_id,
createdAt: data.created_at
};
まとめ:両者の哲学の違いを理解する
| 言語 | 命名文化 | 理由 |
|---|---|---|
| JavaScript | camelCase中心 | Java文化・DOM操作との整合性 |
| PHP | snake_case中心(メソッドはcamel) | C文化・可読性と互換性重視 |
そして、フロントとバックでルールを分けて、変換で橋渡しする のが現代的なベストプラクティスです。
さいごに
命名規則は「正解」よりも「一貫性」が大切。
チームやプロジェクト内でルールを統一しておけば、
コードレビューや保守が圧倒的にスムーズになります。