コーディング標準:何かを嗅ぐ
公開: 2021-07-19ソフトウェア開発と同じくらい長い間、いくつかの質問がありました。 タブまたはスペースでインデントする必要がありますか? コーディング標準は本当に重要ですか? 私は本当にいくつかの恣意的なルールに従って時間を無駄にする必要がありますか?
それぞれ、これらの質問に対する答えは次のとおりです。タブ(明らかに)、はい(それほど明白ではない)、およびいいえ(一種)。

標準の重要性は他の人によって詳細にカバーされているので、ここでは詳しく説明しませんが、その要点は次のとおりです。読みやすさを向上させ、驚きを制限し、貢献できるため、特定のプロジェクト内で内部整合性が望ましいです。コードの堅牢性。
標準を自動的に適用する方法があるので、標準に固執する「時間を無駄にする」必要はありません。
ここで取り上げるのは、 WordPressプロジェクト用のスタンドアロンツールPHP Codesniffer (PHPCS)をすばやく簡単にセットアップする方法です。 これにより、次のことが可能になります。
- コードの標準コンプライアンスに関するレポートを作成する
- さまざまなコンプライアンスの問題を自動的に解決します
以下の例では、WordPress標準を実装します。
インストール
前提条件:
- ターミナルアクセス(WindowsユーザーはBash for Windowsで成功する可能性がありますが、これはテストされていません)
- Composerパッケージマネージャー
PHPCSを単独でインストールすることは可能ですが、デフォルトではWordPressをサポートしていません。 そのために、わかりやすい名前のWordPressコーディング標準(WPCS)をインストールします。
まず、グローバルに使用するためにWPCSをインストールする場所に移動します。
$> cd / path / to / whereever
Composerを使用してパッケージをインストールします。
$>コンポーザーcreate-projectwp-coding-standards / wpcs --no-dev
この時点で、WPCSに飛び込んで使用を開始できますが、コマンドを実行するたびに設定するフラグがいくつかあります。 便宜上、いくつかのエイリアスを設定しましょう。
お気に入りのエディタでホームディレクトリから.profileを開き(または存在しない場合は作成し)、次を追加します。
#WPコーディング標準 export PATH = $ PATH: "/ path / to / whereever / wpcs / vendor / bin" エイリアスwpcs = 'phpcs --standard = WordPress --extensions = php エイリアスwpcbf = 'phpcbf --standard = WordPress --extensions = php
ここに2つのエイリアスを追加しました。1つはphpcs(コンプライアンスの失敗を検出して表示する)用で、もう1つはphpcbf(phpcsによって検出されたさまざまな問題を自動的に修正する)用です。 追加のオプションは次のことを行います。
–standard = WordPress – WordPress標準を適用します(WPCSで設定)
–extensions = php –ターゲットPHPファイルのみ(PHPCSはデフォルトでPHP、CSS、およびJSをターゲットにします)
ターミナル(またはソース.profile )を再起動すると、WPCSはコードをスニッフィングする準備が整います!
スニッフィング
ファイルのスニフレポートを作成するには、次のコマンドを実行します。
$> wpcs /path/to/your/php/project/file.phpこれにより、ターミナルにレポートが出力されます。 または、これをファイルに出力することもできます。
$> wpcs /path/to/your/php/project/file.php> output.txt
スニフレポート
WPCSスニフ出力は次のようになります。


ここにはかなりの量の情報が詰め込まれていますが、非常にきれいにレイアウトされています。 私たちが持っているものを確認しましょう:
- 対象のファイル
- 検出されたエラー/警告の数と影響を受けた行の数の要約
- 見つかった問題のリストと、重大度レベルおよび説明
- phpcbfが自動的に解決できる問題の数の表示(基本的に[x]のすべての問題)
予想されるように、PHPCSはすべてを説明することはできません。 コメントの句読点の選択や特定の種類のコードの書式設定については想定していませんが、さまざまな問題を処理できます。
素晴らしいボーナスは、WordPressルールにより、PHPCSが関数の潜在的な誤用を含むWordPress固有の問題を検出できることです。
修正
問題を自動的に解決することは、これ以上簡単なことではありません。
$> wpcbf /path/to/your/php/project/file.php
短い要約が出力されます。

残りのエラーは手動で修正する必要がありますが、通常、問題のかなりの部分が処理されていることがわかります。
カスタムルール
ルールセットをカスタマイズしたり、プロジェクト内の特定のディレクトリを除外したりすることもできます。 ルールセットのドキュメント注釈付きPHPCSは、あなたが作ることができるすべての変更の例を提供しますが、広くあなたをただ話します。
- ルールセットファイルを作成する
- PHPCSコマンドで参照してください
ルールセットファイルの例を次に示します。
<?xml version = "1.0"?>
<ruleset name = "WordPress Coding Standards">
<description>カスタマイズされたWordPress標準。</ description>
<rule ref = "WordPress">
<exclude name = "Generic.Formatting.MultipleStatementAlignment.NotSameWarning" />
</ rule>
<exclude-pattern> * / bin / * </ exclude-pattern>
<exclude-pattern> * / node_modules / * </ exclude-pattern>
<exclude-pattern> * / tests / * </ exclude-pattern>
</ルールセット>この例では、次のことを行いました。
- WordPressルールセットを参照(WPCSから)
- ルールを除外
- 一部のディレクトリを除外
ルールセットファイルは、WPCSを呼び出すディレクトリ(プロジェクト、テーマ、またはプラグインルートが通常は適切です)に配置し、フラグを介して参照できます。 次のように、.profileの–standardフラグを更新します。
#WPコーディング標準 export PATH = $ PATH: "/ path / to / whereever / wpcs / vendor / bin" エイリアスwpcs = 'phpcs --standard = codesniffer.ruleset.xml --extensions = php エイリアスwpcbf = 'phpcbf --standard = codesniffer.ruleset.xml --extensions = php
WPCSの実行時にフラグが立てられているルールを確認するには、次のように-sフラグを指定して実行します。
$> wpcs -s /path/to/your/php/project/file.php
次は何?
上記のガイドは、WordPressプロジェクトでアドホックな標準コンプライアンスチェックを実行できるようにしますが、それを標準の開発サイクルに統合する場合は、次の論理的なステップは自動化です。
PHPCSをgulpやgruntなどのタスクランナーに統合するか(PHPCSモジュールは両方で使用可能)、それ以外の場合はCI / CDビルドパイプラインに統合することを検討してください。
Webの開発と設計については、今すぐご連絡ください。
ご不明な点がございましたら、お気軽にお問い合わせください。
