【PHPコーディング規約】PSR準拠のルールをコード例で徹底解説

PHPを使ったチーム開発では、しばしばこのような事態に直面します。

複数人で一つのシステムを開発する上で、全員が自分勝手なスタイルでコードを書いてしまうと、コードの可読性や保守性は著しく低下し、バグの温床にもなりかねません。

この問題を解決するために不可欠なのが、チーム全員が守るべき共通のルール、「コーディング規約」です。

この記事では、PHPのコーディング規約について、なぜそれが必要なのかという基本的な理由から、世界標準の規約である「PSR」の解説、そして命名規則やインデントといった具体的なルールまで、豊富なサンプルコードと共に徹底的に解説します。

そもそもコーディング規約とは？なぜ必要なのか？

コーディング規約とは、ソースコードを記述する際の書き方やスタイルに関するルールを定めたものです。

では、なぜコーディング規約が必要なのでしょうか？

それは、以下のような理由があるからです。

複数人開発の効率を上げるため

チーム開発において、コーディング規約がもたらす最大のメリットは、開発効率の向上です。
全員が同じルールに従ってコードを書くことで、他人が書いたコードでも内容を素早く、そして正確に理解できるようになります。

もし規約がなければ、コードレビューの際に「このインデントは見にくい」「変数名が分かりにくい」といった、本来ならば必要がない「スタイルの指摘」に多くの時間を費やすことになってしまいます。

規約を定めることで、このような無駄なコミュニケーションコストを削減し、ロジックの妥当性といった、より重要な部分に集中できるのです。

コードの品質と可読性を保つため

統一されたスタイルで書かれたコードは、非常に読みやすくなります。
インデントや改行、スペースの使い方が一貫しているだけで、コードの構造が直感的に把握しやすくなるからです。

可読性の高いコードは、第三者だけでなく、未来の自分にとっても大きな助けとなります。
数ヶ月後に自分が書いたコードを修正する必要が出たとき、それがぐちゃぐちゃなスタイルで書かれていたら、内容を思い出すのに多大な時間がかかってしまうでしょう。

コーディング規約は、コードという「資産」の品質を長期的に保つための保険なのです。

バグの防止とメンテナンス性向上のため

一貫したコーディングスタイルは、バグの早期発見にも繋がります。

例えば、「変数は必ずスネークケースで書く」というルールがあれば、キャメルケースで書かれた変数を見つけた瞬間に「これは何かおかしい」と気づくことができます。

また、メンテナンス性も飛躍的に向上します。

システムの改修や機能追加を行う際、既存のコードがどのようなルールで書かれているかを解析する手間が省け、迅速かつ安全に修正作業を進めることが可能です。

誰が書いても、誰が読んでも、誰が修正しても品質が落ちない。
これがコーディング規約が目指す理想の状態です。

PHPの標準規約「PSR」を理解しよう

PHPのコーディング規約を語る上で絶対に欠かせないのが、「PSR（PHP Standard Recommendations）」です。

PSRは、PHPの標準的な規約を策定するグループ「PHP-FIG」によって定められた、世界中で広く受け入れられているコーディング標準です。

PSRとは？

PSRは、PHPのフレームワークやライブラリ間の相互運用性を高めることを目的として策定された、一連の仕様書です。

コーディングスタイルだけでなく、オートローディングの規約やHTTPメッセージのインターフェースなど、様々な規約が含まれています。

特定のフレームワークに依存しない、PHPコミュニティ全体の共通ルールであるため、PSRに準拠することで、世界中のPHP開発者にとって読みやすく、再利用性の高いコードを書くことができます。

必ず押さえるべきPSR-1（基本コーディング規約）

PSR-1は、すべてのPHPコードが最低限準拠すべき、最も基本的なルールを定めています。

ファイル形式やクラス・メソッドの命名規則などが含まれており、いわば「PHPコードの憲法」のようなものです。

PSR-1の主なルール
PHPコードは <?php または <?= タグで開始する。
ファイルはBOMなしのUTF-8でのみ保存する。
クラス名は StudlyCaps（アッパーキャメルケース）で定義する。
クラス定数はすべて大文字で、区切り文字はアンダースコア（_）とする。
メソッド名は camelCase（ローワーキャメルケース）で定義する。

現代の標準スタイル PSR-12（拡張コーディングスタイルガイド）

PSR-12は、PSR-1を土台として、より具体的なコーディングスタイル（インデント、制御構造、スペースの入れ方など）を定めた規約です。

以前はPSR-2がその役割を担っていましたが、2019年にPSR-12がその後継として勧告されました。

2025年現在、PHPのコーディングスタイルについて語る場合、このPSR-12に準拠することが事実上の標準となっています。

この記事で紹介する具体的なルールも、主にこのPSR-12に基づいています。

【PSR準拠】PHPコーディング規約の具体的なルール10選

それでは、PSR-1およびPSR-12に基づいた、具体的なコーディングルールをサンプルコードと共に見ていきましょう。

PHPタグの記述方法

PHPコードを記述するファイルでは、必ず <?php タグから書き始める必要があります。
<? のような短縮形の開始タグは使用してはいけません。

また、ファイル全体がPHPコードのみで構成される場合は、終了タグ ?> は省略することが推奨されています。
これは、ファイルの末尾に意図しない空白文字などが出力されるのを防ぐためです。

【良い例】

<?php
echo 'Hello, World!';

// PHPコードのみなので終了タグは書かない

【悪い例】

<? // 短縮形はNG
echo 'Hello, World!';
?> <!-- HTMLが混在しない場合は省略する -->

ファイルの文字エンコーディング

すべてのPHPファイルは、必ず「BOMなしUTF-8」で保存しなければなりません。

BOM（Byte Order Mark）は、ファイルの先頭に付与される不可視のデータで、これが含まれていると、意図しない出力やヘッダー送信エラーの原因となることがあります。

使用しているエディタの設定を確認し、保存形式が「UTF-8 (BOMなし)」または「UTF-8」となっていることを確認してください。

命名規則（変数、クラス、メソッド、定数）

命名規則は、コードの可読性を左右する最も重要なルールの一つです。
PSRでは、対象によって明確にケース（大文字・小文字の使い分け）が定められています。

対象	命名規則	例
クラス名	スタッドリーキャップス（StudlyCaps）	UserController, DatabaseConnection
メソッド名	キャメルケース（camelCase）	getUserName(), calculateTotalPrice()
クラス定数	大文字のスネークケース（UPPER_SNAKE_CASE）	const VERSION = '1.0';, const MAX_LOGIN_ATTEMPTS = 5;
プロパティ名	キャメルケース（camelCase）	private $userName;, public $lastLoginDate;
変数名	キャメルケース（camelCase）	$userName, $itemPrice

【良い例】

<?php
class UserProfile
{
    public const MAX_NAME_LENGTH = 255;
    private $userName;

    public function setUserName($name)
    {
        $this->userName = $name;
    }
}

【悪い例】

<?php
class user_profile // NG: スネークケース
{
    const max_name_length = 255; // NG: 小文字
    private $user_name; // NG: スネークケース

    public function SetUserName($Name) // NG: スタッドリーキャップスや大文字始まり
    {
        $this->user_name = $Name;
    }
}

インデントは「スペース4つ」

コードのインデントには、タブではなく「スペース4つ」を使用しなければなりません。

タブ文字は、閲覧する環境によって表示される幅が異なるため、コードの見た目が崩れる原因となります。
スペースであれば、どの環境でも同じように表示されるため、インデントの統一性が保たれます。

多くのエディタでは、Tabキーを押した際に自動でスペース4つが挿入されるように設定できます。

【良い例】

<?php
if ($condition) {
    // スペース4つでインデント
    echo 'Condition is true.';
}

制御構造（if、else、for、foreach）の書き方

if、elseif、else、for、foreach、while などの制御構造は、書き方のルールが細かく定められています。

【良い例】

<?php
if ($a > $b) {
    echo 'a is greater than b';
} elseif ($a < $b) {
    echo 'a is smaller than b';
} else {
    echo 'a is equal to b';
}

【悪い例】

<?php
if($a>$b){ // NG: スペースがない
    echo 'a is greater than b';
}
else // NG: 中括弧が別々の行にある
{
    echo 'a is equal to b';
}

演算子の前後のスペース

比較演算子（==, !=など）、代入演算子（=）、算術演算子（+, -など）、論理演算子（&&, ||など）といった、二項演算子の前後には、必ずスペースを1つずつ入れなければなりません。

これにより、式が読みやすくなります。

良い例:

<?php
$sum = 1 + 2;
$isValid = ($age >= 20) && ($isMember === true);

悪い例:

<?php
$sum=1+2; // NG: スペースがない
$isValid = ($age>=20)&&($isMember===true); // NG: スペースがない

メソッド・関数の定義

メソッドや関数の定義にも、明確なスタイルルールがあります。

【良い例】

<?php
class SampleClass
{
    public function sampleFunction(int $arg1, string $arg2, array $arg3 = [])
    {
        // メソッドの処理
    }
}

【悪い例】

<?php
class SampleClass
{
    public function sampleFunction ($arg1, $arg2) { // NG: 中括弧の位置、引数括弧の後のスペース
        // メソッドの処理
    }
}

クラスの定義とプロパティ

クラスの定義は、メソッドと同様に、開始の中括弧 { をクラス名の次の行に配置します。

また、プロパティやメソッドには、必ず public, protected, private のいずれかの可視性を明示する必要があります。

そして、var を使ったプロパティ宣言は禁止されています。

【良い例】

<?php
class User
{
    public $id;
    protected $name;
    private $password;

    public function __construct($id)
    {
        $this->id = $id;
    }
}

コメントとPHPDocの書き方

コードの意図を伝えるために、コメントは重要です。
一行コメントには // を、複数行コメントには /* */ を使用します。

さらに、クラス、プロパティ、メソッドなどには、PHPDoc（ドックブロック）と呼ばれる /** */ で囲まれた形式のコメントを記述することが強く推奨されます。

PHPDocには、機能の概要、引数の型や説明、戻り値の型などを記述することで、IDEがコード補完に利用したり、ドキュメントを自動生成したりできます。

【良い例】

<?php
/**
 * ユーザーに関する処理を行うクラス
 */
class UserController
{
    /**
     * ユーザーIDを基にユーザー情報を取得します。
     *
     * @param int $userId ユーザーID
     * @return array|null ユーザー情報配列。見つからない場合はnull。
     */
    public function findUserById(int $userId): ?array
    {
        // ...処理
        return null;
    }
}

1行の文字数と改行のルール

1行のコードの長さは、80文字をソフトリミット（推奨）、120文字をハードリミット（必須）とすることが定められています。

長い行は、横スクロールが発生し、コードの可読性を著しく低下させるためです。

メソッドの引数リストや配列の定義など、1行が長くなる場合は、適切に改行を行います。
改行した場合は、次の行はスペース4つでインデントします。

【良い例】

<?php
$longArray = [
    'long_key_1' => 'value_1',
    'long_key_2' => 'value_2',
    'long_key_3' => 'value_3',
];

$user = $userRepository->find(
    $id,
    $withProfile,
    $withPosts
);

コーディング規約を自動でチェック・修正するツール

これらのルールをすべて覚えて、手作業で遵守するのは非常に大変です。

そこで活用したいのが、コーディング規約を自動でチェック・修正してくれるツールです。
これらを導入することで、規約の遵守が簡単かつ効率的になります。

静的解析ツール「PHP_CodeSniffer」

PHP_CodeSniffer（phpcs）は、PHPコードが指定したコーディング規約に準拠しているかをチェックしてくれるツールです。

PSR-12のルールセットも標準で用意されており、コマンドを実行するだけで、規約違反の箇所を一覧で表示してくれます。

多くのエディタやIDEと連携でき、コードを保存するたびに自動でチェックを実行させることも可能です。

自動整形ツール「PHP-CS-Fixer」

PHP CS Fixerは、規約違反をチェックするだけでなく、自動で修正（整形）まで行ってくれる非常に強力なツールです。

--rules=@PSR12 のようにルールを指定して実行するだけで、インデントの乱れやスペースの不足などを、PSR-12の規約通りに一括で修正してくれます。

手作業での修正漏れを防ぎ、誰でも一瞬で規約に準拠した綺麗なコードを生成できます。

フレームワークごとのコーディング規約

PSRはPHP全体の標準ですが、LaravelやCakePHPといった主要なフレームワークは、PSRをベースにしつつ、独自のコーディング規約を定めている場合があります。

Laravelのコーディング規約

Laravelは、PSR-2（現在はPSR-12が後継）に準拠しています。
Laravelを利用して開発を行う場合は、基本的にPSR-12のルールに従っていれば問題ありません。

Laravelプロジェクトには、PHP-CS-Fixerの設定ファイルが最初から含まれていることも多く、規約の遵守が容易になっています。

CakePHPのコーディング規約

CakePHPも、PSR-1およびPSR-2（PSR-12）をベースとしたコーディング規約を採用しています。

それに加えて、変数名の付け方やコメントの書き方など、フレームワーク独自のより詳細なルールが定められています。

CakePHPで開発を行う際は、公式ドキュメントで独自の規約を確認することが推奨されます。

チームでコーディング規約を導入する際のポイント

最後に、これから自分のチームにコーディング規約を導入しようと考えているリーダーやマネージャーの方向けに、成功のための3つのポイントを紹介します。

既存の規約（PSR）をベースにする

ゼロから独自のコーディング規約を作成するのは、膨大な労力がかかる上に、独りよがりなルールになりがちです。

まずは、世界標準であるPSR-12をベースとして採用し、チームでどうしても譲れない部分だけをカスタマイズする、というアプローチが最も効率的で確実です。

ツールで自動化し、個人の負担を減らす

規約は、作って終わりではありません。
守られて初めて意味があります。

PHP_CodeSnifferやPHP-CS-Fixerといったツールを導入し、コミット時に自動でチェック・整形が走る仕組み（Gitフックなど）を構築しましょう。

これにより、「規約を守る」という行為が個人の努力ではなく、開発プロセスの一部として自動化され、形骸化を防ぐことができます。

最初から完璧を目指さない

特に、これまで規約がなかったチームに導入する場合、最初からすべてのルールを厳格に適用しようとすると、メンバーからの反発を招く可能性があります。

まずは、「インデント」や「命名規則」といった、効果が大きく分かりやすいルールから始め、徐々に適用範囲を広げていくのがよいでしょう。

目的はルールで縛ることではなく、あくまで開発効率と品質を向上させることであることを忘れないでください。

まとめ

この記事では、PHPのコーディング規約について、その重要性から世界標準であるPSRの解説、具体的なルール、そして効率的な運用方法までを幅広く解説しました。

なお、PHPを体系的に学んだり、PHPのスキルを高めたりするためには、プログラミングスクールを利用するのも有効です。

細かな疑問がすぐに解決するだけでなく、現役エンジニアが「質の高いポートフォリオ」を作成するための手助けをしてくれたり、エンジニア就職・転職のコツを教えてくれたりするなど、様々なメリットがありますので、独学に疲れた方は検討してみてはいかがでしょうか。