PSR入門：PHPのコーディング規約について

今日は、PHPにおけるPSRについてご紹介します。

背景

業務上、PSR-7やPSR-11など、PHPのコーディング規約について調べることがありましたので、自分の頭の中の整理も含めて、記事にしました。

PSRとは

PHP-FIG (PHP Framework Interop Group) は、PHPコミュニティ内でコードの互換性と標準化を推進するためのグループです。PHP-FIGが定めた規約のことをPSR（PHP Standards Recommendation）と呼びます。これにより、異なるPHPプロジェクト間でコードをより簡単に共有し、相互運用性を向上させることができます。

PSR一覧

PSRには下記の一覧があります。

NUM	TITLE	STATUS
0	Autoloading Standard	Deprecated
1	Basic Coding Standard	Accepted
2	Coding Style Guide	Deprecated
3	Logger Interface	Accepted
4	Autoloading Standard	Accepted
5	PHPDoc Standard	Draft
6	Caching Interface	Accepted
7	HTTP Message Interface	Accepted
8	Huggable Interface	Abandoned
9	Security Advisories	Abandoned
10	Security Reporting Process	Abandoned
11	Container Interface	Accepted
12	Extended Coding Style Guide	Accepted
13	Hypermedia Links	Accepted
14	Event Dispatcher	Accepted
15	HTTP Handlers	Accepted
16	Simple Cache	Accepted
17	HTTP Factories	Accepted
18	HTTP Client	Accepted
19	PHPDoc tags	Draft
20	Clock	Accepted
21	Internationalization	Draft
22	Application Tracing	Draft

STATUSには、下記の意味があります。

Deprecatedは、廃止されたことを意味します。そのため、この規約に準拠することは推奨されていません。

Abandonedは、放棄を意味します。積極的に取り組まれずに放置された状態だといえます。

Draftは、草案を意味します。FIG コア委員会による審議・検討がなされている状態だといえます。そのため、この規約は変更される可能性があります。

Acceptedは、承認済みを意味します。そのため、正式にPSRとして勧告されたものとしてあつかえます。

PSRワークフロー細則によると、各PSRには作業中のステータスがあります。一旦エントランスボートを通過した提案は、”Draft”として掲載されます。PSRが “Accepted “と表示されない限り、変更される可能性があります。”Draft”は大幅に変更される可能性がありますが、レビューは軽微な変更に留まります。

考察

PSR（PHP Standards Recommendation）にはいくつかのメリットがありますが、同時にいくつかのデメリットも存在します。以下にそれぞれを説明します。

メリット:

1. コードの互換性と相互運用性の向上: PSRに従うことで、異なるPHPプロジェクト間でコードをより簡単に共有できるようになります。これにより、フレームワークやライブラリの組み合わせが容易になり、相互運用性が向上します。
2. コードの一貫性と可読性の向上: PSRはコーディングスタイルや規約を統一するため、コードベース全体で一貫性が保たれ、コードの可読性が高まります。これにより、他の開発者がコードを理解しやすくなり、メンテナンスが容易になります。
3. コミュニティとの連携: PSRはPHPコミュニティ全体で作成される標準なので、PHP開発者はより広いコミュニティと連携しやすくなります。コードを共有しやすくなることで、多くの開発者が貢献することが期待されます。

デメリット:

1. 柔軟性の低下: PSRに従うことは、一定の制約を受け入れる必要があります。プロジェクトの特定の要件に合わせてカスタマイズしたい場合、PSRの規約により柔軟性が低下する可能性があります。
2. 適用範囲の限定: PSRは主にフレームワークやライブラリの開発に焦点を当てており、個別のアプリケーションに対して適用されることは少ないかもしれません。特定のプロジェクトに合わない場合もあります。
3. 更新の遅れ: PHP-FIGは新しいバージョンのPSRを定期的に提案していますが、更新が遅れる場合もあります。したがって、最新のPHP機能やベストプラクティスに対応できないことがあります。

総合的に見ると、PSRはPHPコミュニティのコード品質と相互運用性を向上させる有用な取り組みですが、すべてのプロジェクトに完全に適応できるわけではないことを理解しておく必要があります。

プロジェクトの特定の要件や制約に基づき、PSRの規約を適用するかどうかを判断する必要があります。また、PSRはあくまで推奨事項であり、必ずしも従う必要はありません。プロジェクトのニーズやチームの合意に基づいて、PSRの一部を適用するか、独自の規約を定めるかを決定することができます。

おわりに

今日は、PHPにおけるPSRについてご紹介しました。

最終的には、PSRはPHPコミュニティ内でのコードの互換性と共有性を高めるための指針であり、一貫性と可読性の向上に役立つことが多いです。ただし、プロジェクトの特定の要件や制約に合わない場合や、柔軟性や更新の遅れに対応する必要がある場合は、適切に検討することが重要です。

公式サイトは下記になります。