PHPerのための「PHP標準コーディングルール（PSR）について語り合う」 TechCafe

PHPerのための「PHP標準コーディングルール（PSR）について語り合う」 TechCafe ========================================= # PSRとは？ https://www.php-fig.org/psr/ PHP標準コーディング~~規約~~「勧告」のこと。採用するときは、**100%準拠する必要はない**。 * PHPerはPSRとはどう付き合って行くべき？ * PHPerにとってPSRはどう役に立つ？どんなものなのか * https://www.php-fig.org/faqs/ * "PHP Standard Recommendation" の略 * PHP-FIG（Framework Interoperability Group）によって策定されている ## PHP-FIG とは ![](https://i.imgur.com/oNmcAAR.png) PSRの作成を行っている、PHPのフレームワークやツールなどのプロジェクト開発者によって構成されている組織。 ### PHP-FIG の目的 ``` このグループの背景にある考えは、プロジェクトの代表者が互いのプロジェクトの共通点について話し合い、協力し合える方法を見つけることです。私たちの主な参加者はお互いに、他のPHPコミュニティが注目していることもよく知っています。もし他の人たちが私たちのやっていることを採用したければ歓迎しますが、それが目的ではありません。このグループの誰もが、プログラマーであるあなたに、アプリケーションの作り方を教えようとは思っていません。 ``` - プロジェクトの代表者が互いのプロジェクトの共通点について話し合い、協力し合う - もし私たちのやっていることを採用したい場合は歓迎するが、それが目的ではないつまり、フレームワークやライブラリの開発者がお互いの利益のために相互に話し合って策定された結果であって、全てのPHPエンジニア、およびプロダクトに対して準拠を促すもの**ではない。** **…のだが、** あたかも正統な「規約」であり、準拠することが正しい、というような誤った理解がされていることが多いようです。 ### PHP-FIG のメンバー * https://www.php-fig.org/personnel/ * メジャーなフレームワークやツールのプロジェクトが関わっている * CakePHP, Composer, Magento, PEAR, Phalcon, Slim… * 過去には、Laravel, Symfony, Doctrine, Guzzle, Propelなどのプロジェクトも関わっていた（現在は離脱） * Symfonyは離脱してはいるが一部準拠 * [Symfonyコーディング規約](https://symfony.com/doc/current/contributing/code/standards.html) * [Symfonyが離脱した理由](https://hub.packtpub.com/symfony-leaves-php-fig-the-framework-interoperability-group) * FIGで議論されている内容は、「フレームワーク間の相互強調ではなく、FIGが作ろうとしている**頑固な新しいフレームワーク**である」、と主張されている。 * そしてその内容はSymfonyが求めているものではないので、離脱する、ということのようです。 * Laravelは離脱しているが一部採用 * [Laravelコントリビュートガイド](https://laravel.com/docs/8.x/contributions) * LaravelはPSR-2コーディング標準とPSR-4自動読み込み標準に準拠 * 「離脱してるのに準拠してる」っていうのはどういう状況？ - 最初は協力体制で作ってたけど、意見合わんくなってきたから抜けるわ - せやけど、使えそうなところはそのまま使うんで、みたいな感じ  ## PSR の策定プロセス ### 登場人物 * [コア委員会](https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee) * [ワーキンググループ](https://www.php-fig.org/bylaws/mission-and-structure/#working-groups) ### プロセス * Pre-Draft * 「PSRとして検討していくべきかどうか」の判断フェーズ * ワーキンググループによって提案をまとめる * 編集者１人＋コアメンバー1人（スポンサー）＋他３人が最小構成 * 提案には、少なくとも、以下が含まれていなければならない * 解決すべき問題の記述 * 取るべき一般的なアプローチに関する基本情報 * 提案に対し、コア委員会による入口投票を実施し、可決されれば次のフェーズへ * Draft * 草案をまとめるフェーズ * ワーキンググループのメンバーによって議論・作成が行われる * Githubやメーリングリストで実施 * PHP-FIGのメンバーでなくとも、意見を述べる事ができる * ワーキンググループによる準備投票を実施し、可決されれば次のフェーズへ * Review * 提案の実用性を評価するフェーズ * 仕様の試験的な実装を行い、提案に大きな変更が必要であればDraftに戻す * 最低４週間、2つ以上の試験的実装が行われた段階で、受託投票を行う * 受託投票は、コア委員会メンバーによって行われる * Accepted * 承認された状態 * ワーキンググループは解散 * Deprecated * 非推奨となった状態 * 一度は承認されたが、新しいPSRに取って変わられたなどの理由で不要となったもの * コア委員会メンバーによって発議・投票で決定される * Abandoned * 放棄された状態 * 積極的に作業が行われていない。編集者／スポンサーが不在の状態が60日以上すぎた場合、書記によって「放棄」指定を受ける * コア委員会による廃棄投票で可決された場合、廃棄される # どのようなことが書いてあるの？ https://www.php-fig.org/psr/ 大きく以下の[カテゴリー](https://www.php-fig.org/)に分類される。 * オートローディング * インタフェース * HTTP * コーディングスタイル一部抜粋 * PSR-1 * [1. Basic Coding Standard](https://www.php-fig.org/psr/psr-1/) * ファイルではタグ `<?php` もしくは`<?=` のみを使用する（MUST） * PHPコードのファイルではBOMなしのUTF-8のみを使用する（MUST） * ファイルはシンボル（クラス、関数、定数など）を宣言するか、副作用（出力の生成、.iniの設定変更など）を起こすかのどちらかであるべきで、その両方を行ってはならない（SHOULD） * 名前空間とクラスは ”autoloading” に従わなければならない [PSR-0] [PSR-4] （MUST） * クラス名はスタッドリーキャップスで宣言する（MUST） * クラス定数は、全て大文字でアンダースコア区切りを利用して宣言する（MUST） * メソッド名はキャメルケースで宣言する（MUST） * PSR-12, PSR-2 * [12. Extended Coding Style Guide](https://www.php-fig.org/psr/psr-12/) * 拡張コーディングスタイル * PSR-2 のコーディングスタイルガイドの拡張となる * ※PSR-2は PSR-1 の拡張という位置づけ * つまりPSR-12に準拠しているということは、PSR-1, PSR-2 に準拠しているということ * PSR-12の位置づけ * それまで存在していたPSR-2とは異なる全く新しいコーディングスタイルのガイドラインを追加することは意図していない * PSR-2はPHP機能の包括的な内容に関するコーディングスタイルのガイドラインとして優れたいたが、新機能追加などによって解釈の自由が増えたため、PSR-12が誕生した * PSR-12 の目的 * 異なる開発者のコードを理解する際の可読性向上 * 共有されたルールとPHPのコードフォーマットのルールの一般化 * 導入に向けて * 細かいルールも守っていきたいが、システムで自動化したい・・・。 * 長年同じプロダクトを開発していると既存のコーディングルールの方に目が慣れているため違和感が無くなってきている * まずは、1回全体を綺麗にコード整形して、チーム全員の目を慣らしていくなどのテコ入れが必要な気がする * PSR-8 * [8. Huggable Interface](https://github.com/php-fig/fig-standards/tree/master/proposed/psr-8-hug) * オブジェクトがハグすることによって相互の感謝とサポートを表現するための共通の方法を確立します。これにより、オブジェクトは建設的な方法で相互にサポートし、異なるPHPプロジェクト間の連携を促進できます。 * 実は [Larry Garfield](https://twitter.com/crell)(PHP-FIGのコアメンバー) が 2014年のエイプリルフールに提案したネタ * PSRの投票プロトコルは「投票メンバーの3分の1以上が投票期間内に賛成投票する」が条件 * 当時、35名の投票メンバーがいたが14票の賛成票が投じられました。当時の可決にいたるしきい値は12だったため、この投票は可決されました。 * 当時の様子 * https://groups.google.com/g/php-fig/c/pcCMC6Kpq74/m/fEhWihgz_zMJ * [ClockInterface](https://www.reddit.com/r/PHP/comments/m1snd3/proposal_for_new_psr_for_clockinterface/) * 時間操作系のインターフェース（現在Draft中） * 時間に関するテストを実施する際に、現在の時間を表す方法を統一させたい * -packagistの検索によると、この問題に対して約10の競合するライブラリが存在するとのこと * https://groups.google.com/g/php-fig/c/lA8Lz0E4dWk # PSRの活用状況は？ ## 利用しているOSS ### Laravel https://search.readouble.com/?query=PSR+8.x * PSR-2: Coding Style Guide * PSR-4: Autoloading Standard * PSR-7: HTTP Message Interface * PSR-11:Container Interface ### Symfony https://symfony.com/search?q=PSR * PSR-1: Basic Coding Standard * PSR-2: Coding Style Guide * PSR-4: Autoloading Standard * PSR-6: Caching Interface * PSR-7: HTTP Message Interface * PSR-12:Extended Coding Style Guide * PSR-16:Simple Cache ### CakePHP https://book.cakephp.org/3/ja/search.html?check_keywords=yes&area=default&q=PSR * PSR-0: Autoloading Standard * PSR-2: Coding Style Guide * PSR-3: Logger Interface * PSR-4: Autoloading Standard * PSR-7: HTTP Message Interface ## PSRの導入を助けるあれこれ ### PHP_CodeSniffer * PSRに則ったコーディングスタイルチェックが可能 * PSR-1とPSR-12は、標準でチェックしてくれる ### Composer * PSR-4に準拠したオートローディングサポート * composer.jsonにベンダー名前空間と実際のディレクトリの紐付けを定義すれば使えるようになる ### Packagist * https://packagist.org/packages/psr/ * PSRに準拠したインターフェースをPHP-FIGが公開している * Composer を使ってインストール可能