请务必在WordPress项目中引入编码规范！
本篇文章是针对WordPress Advent Calendar 2017 12日目的参赛作品。
关于编码规范
はじめに
コーディング規約使ってますか？
コーディング規約はPHPやHTMLを書くときのルールです。
日本語には句読点やカギカッコ、字下げなどに一定のルールがあります。英語でもカンマ、ピリオドの打ち方、スペーシングの使い方にルールがあります。
プログラムやHTMLコードでもそれぞれのルールがあり、そのルールをまとめたものがコーディング規約と呼ばれています。
その規約を守ることで可読性の高いコードを書くことができます。特に複数人でコードを見る機会がある場合にはとても便利になります。
またコーディング規約には明確な「答え」があるので、迷うことが少ないです。
答えに沿ってコーディングをすればよいので、コーディングのレベルアップにつながるなー、と思っています。
我之前已经写了一篇文章介绍如何使用，现在我又在实际工作中使用了一次，所以我总结了这个过程。
为什么要引入编码规范
コーディング規約は「コードを読みやすくすること」です。
コードを読みやすくするメリットは下記のとおりです。
-
他人、特にチームメンバーで読みやすい
バグを防ぎやすい
未来の自分にも優しい
他人の書いたコードは本当に読みにくいですよね。
WordPress的编码规范。
Note: The given phrase is already in Japanese.
光是对编程规范而言，不同的语言和环境会有各种各样的规定。
在WordPress中，它有自己独特的编码规范。
大致上可以概括全面的特征
-
スペースは多めに開ける（丸括弧、波括弧の前後など）
改行も多めに入れる（CSSセレクタ、メソッド類）
推荐您阅读这些定义，因为它们并不特别长。
引入途径
WordPress的文件架构
我打算进行的是“基于WordPress的主题创建项目”。
在实际工作中，如果是WordPress项目，大多数情况下会是主题创建。
这次作为例子，我们使用了_s来创建主题。
文件结构是这样的。
我將這個存儲庫放在了這裡。
在Composer中安装PHPCS、WPCS和PHP Compatibility。
现在我们来试试将PHPCS应用于WordPress主题。
首先，在Composer中安装PHPCS（PHP Code Sniffer）。
Composer有两种安装方式，一种是在整个机器环境中进行全局安装，另一种是针对每个项目（存储库）进行本地安装。
（即使名称为“全局”，如果本地安装的名称有所不同，还请见谅 参考：https://getcomposer.org/doc/00-intro.md#locally）
$ composer require --dev squizlabs/php_codesniffer
接下来，我们将安装WordPress编码规范的代码集合。
https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards
这个编码准则的规则集使用了WPCS（WordPress Coding Standards）的缩写。
$ composer require --dev wp-coding-standards/wpcs
接下来，我们需要安装一个用于检查每个PHP版本的语言兼容性的规则集，即PHP Compatibility。
您可以在以下链接找到该规则集的安装文件：https://github.com/wimg/PHPCompatibility
$ composer require --dev wimg/php-compatibility
完成上述步骤后，我们可以使用”phpcs -i”命令来确认已导入的规则集。
添加WPCS，PHP Compatibility的规则集到PHPCS。
接下来，我们需要为最初安装的PHPCS设置WPCS和PHP Compatibility的规则集。
$ ./vendor/bin/phpcs --config-set installed_paths `pwd -P`/vendor/wp-coding-standards/wpcs,`pwd -P`/vendor/wimg/php-compatibility
我在多次使用PHPCS之后，发现在加入这个规则集时容易遇到问题，所以需要注意。
以下是需要注意的要点。
-
呼び出すPHPCSの実行ファイルの場所に注意すること。（PHPCSをグローバルインストールした場合とローカルインストールした場合で違う。今回はローカル。）
追加するルールセットは絶対パス（若しくはPHPCSをからの相対パス）で記述すること。問題回避のために絶対パスの方が良さそう。
–config-set で設定した値はconfファイルで確認できる。
複数のルールセットを定義する場合にはカンマ区切り。
今回はComposerでローカルインストールを行ったので、./vendor/bin/phpcsを呼び出してコンフィグをセットします。
ここでグローバルなphpcsを呼んでしまうと別の設定になってしまうので注意が必要です。
追加的规则集最好使用绝对路径。
特别是根据 pwd -P 命令获取的仓库根目录的绝对路径进行设置，可以减少错误的发生。
（例如，pwd -P/vendor/wimg/php-compatibility）
如果配置未正常运行，则可以查看CodeSniffer.conf文件来解决问题。
$ cat ./vendor/squizlabs/php_codesniffer/CodeSniffer.conf
<?php
$phpCodeSnifferConfig = array (
'installed_paths' => '/Users/yousan/git/wpcs-1/vendor/wp-coding-standards/wpcs,/Users/yousan/git/wpcs-1/vendor/wimg/php-compatibility',
)
?>
实际试着去动一动
_sのテーマファイルの場合、phpcs.xmlがサンプルでついてきています。
そちらを基に動かしてみます。
您可以使用以下命令来运行。
$ ./vendor/bin/phpcs --standard=./themes/wpcs/phpcs.xml
你动了！
エラーがたくさん出てきました。
これらのエラーを直していくことになります。
此外，在错误消息的底部还写着”可以自动格式化！”。
实际上，对于一些简单的代码规范违规，可以使用PHPCS附带的PHPCBF（PHP美化和修复工具）进行修复。
因此，我们尝试进行自动格式化。
$ ./vendor/bin/phpcbf --standard=./themes/wpcs/phpcs.xml
太厉害了！
你可以通过Git实际上看到哪些部分被修复了。
Composer更新时config被覆写的问题及解决方法。
上で行った通り、PHPCSでは設定ファイルをvendor配下のconfigファイルに保存しています。
そのため composer update や composer install を行うとそのconfigファイルが上書きされて動かなくなってしまうことがあります。
それを防ぐために composer update や composer install を行った際に再度設定をするようにします。
"scripts": {
"post-update-cmd": [
"phpcs --config-set installed_paths `pwd -P`/vendor/wp-coding-standards/wpcs,`pwd -P`/vendor/wimg/php-compatibility"
],
"post-install-cmd": [
"phpcs --config-set installed_paths `pwd -P`/vendor/wp-coding-standards/wpcs,`pwd -P`/vendor/wimg/php-compatibility"
],
...
应该适用哪个协议
ここまで適用してきたPHPCSでは、themes/wpcs/にあるphpcs.xmlというファイルを使っていました。
phpcsコマンドでは–standardで与える設定XMLファイルを基に、どういった規約を適用するか、ということを決めることが出来ます。
WordPressではコーディング規約を定めていますが、プロジェクトによっては外したい規約もあるかと思います。
実際に僕が外している規約について紹介します。
以下是在项目中实际使用的配置文件。
<!-- Include the WordPress ruleset, with exclusions. -->
<rule ref="WordPress">
<!-- _sのルールセットを参照 @link https://github.com/Automattic/_s/blob/master/codesniffer.ruleset.xml -->
<exclude name="Generic.WhiteSpace.ScopeIndent.IncorrectExact" />
<exclude name="Generic.WhiteSpace.ScopeIndent.Incorrect" />
<!-- 長めの関数の呼び出し時に複数行にしなければならない制約を無視 -->
<exclude name="PEAR.Functions.FunctionCallSignature.Indent" />
<!--<exclude name="Generic.WhiteSpace.ScopeIndent.IncorrectExact" />-->
<!--<exclude name="Generic.WhiteSpace.ScopeIndent.Incorrect" />-->
<!--<exclude name="Squiz.Commenting.ClassComment" />-->
<!--<exclude name="Squiz.Commenting.FunctionComment" />-->
<!--<exclude name="Generic.Commenting.DocComment" />-->
<exclude name="WordPress.VIP" />
<!-- 固定ページ内にクラスを入れることを許容 -->
<exclude name="WordPress.Files.FileName.InvalidClassFileName" />
<!-- ファイル名の決定時にslugをサポートするため、page-hoge_fuga.php を許容する -->
<exclude name="WordPress.Files.FileName.NotHyphenatedLowercase" />
<!-- HTML系のエスケープ強制を無視 -->
<exclude name="WordPress.XSS.EscapeOutput.OutputNotEscaped" />
<!-- 管理バーの非表示を許容 -->
<exclude name="WordPress.VIP.AdminBarRemoval.RemovalDetected" />
<!-- コメント分の末尾をフルストップ、ビックリマークやはてなで終わらせる必要があるルールを除外する -->
<exclude name="Squiz.Commenting.InlineComment.InvalidEndChar" />
<exclude name="Squiz.Commenting.FunctionComment.ParamCommentFullStop" />
<!-- コメント文は大文字で始める制約を除外 ex.) iframeについて -->
<exclude name="Generic.Commenting.DocComment.ShortNotCapital" />
<!-- _sのテーマに元々ある多言語化周りの警告を無視する -->
<exclude name="WordPress.WP.I18n.MissingTranslatorsComment" />
<!-- PHPの開始タグ、閉じタグ <?phpと?> を独立した行に置かなければならない条件を除外 -->
<exclude name="Squiz.PHP.EmbeddedPhp.ContentAfterOpen" />
<exclude name="Squiz.PHP.EmbeddedPhp.ContentAfterEnd" />
<exclude name="Squiz.PHP.EmbeddedPhp.ContentBeforeOpen" />
<exclude name="Squiz.PHP.EmbeddedPhp.ContentBeforeEnd" />
<!-- 引数の説明を省略可能にする -->
<exclude name="Squiz.Commenting.FunctionComment.MissingParamTag" />
</rule>
试着引入
试用之后的想法
最近几年来，我负责的项目逐渐变得庞大，并且我作为领导者在和多人一起开发的情况下增加了。不仅限于WordPress，作为项目负责人，我需要查看提交的代码、解决错误故障以及在缺员时帮助。但是，代码有着工程师的个人习惯和偏好，我总觉得读起来不太舒服。因此，为了解决这个问题，我在WordPress项目中引入了PHPCS。虽然WordPress的编码规范维基已经周知了“我们要遵守这个规范”，但实际上人们无法始终如此。通过使用PHPCS，我几乎可以强制团队成员遵守规范，非常方便。感谢PHPCS！
特别是PHPCS可以被整合到CI中。 在要求团队成员审阅拉取请求之前，通过将PHPCS作为测试工具，可以排除编码规范的违规情况。 这非常有帮助。
所以希望大家都能过上美好的自动化生活！
明天是由@ozy-san先生主持的「使用OPCache＆APCu＆SSL将WordPress迁移到ConoHa并进行新设置」活动。
