かつては、プログラマー、個々のタスク、さらにはプロジェクトの狭い輪で作業していましたが、スタッフの離職に伴う問題については考えていませんでした。 より正確に考えるために-彼らは考えたが、何の対策も講じなかった、そして全体として、チームは緊密であり、誰も残らず、誰も残らなかった。 内部プロジェクトと企業クライアントの成長に伴い、スタッフが成長し始め、すべてが順調であるように思われました。 「無駄な」議論、チェック、過剰な設計などに多くの時間を費やし始めました。最も厄介なのはコードのチェックです。 そして、私は「賢明で古代の」人がおそらく数百、数千のプログラマーでこれらの問題を解決したと考え始めました。本当に対処できないのでしょうか？ 「コミットを使用した自動コードスタイルチェック」という実験を行うことにしました。 ほとんどの人にとって、これはニュースではなく、おそらくそれを使用するでしょうが、実装の経験を共有することは不必要ではないと思います。
日曜日、3：40
この早い時間に、職場に座ってお茶を飲んで、明日はオフィスに行き、午前中に再び2〜3時間を費やしてコードをチェックし、さらに2時間をかけてタスクを設定する必要があると思いました2時間後に家に帰ります。 そしてもちろん、残りの2〜3時間に設定したタスクを解決することはできません。また、これらの問題を都合の悪いときに解決することで、家族などを破壊することもできます。 これは続行できません。 まず第一に、私は「ケルベロス」ではなくプログラマーであり、検証プロセスを自動化する必要があります。検証プロセス全体を削除しなければ、少なくともそれを減らします。
私は車輪を再発明したくないので、すぐに検索エンジンに目を向けて、「コーディング標準PHPの確認」、上位10の結果を見て、頻繁に出会う名前「
PHP_Codesniffer 」に気づき、同じ名前を尋ねました-自動コードスタイルチェック用のPEARライブラリであることがわかりました彼らが言うように-「医師が注文したもの！」と開発者の信頼性は、これが可能なグローバルな実装に有益な効果をもたらすことは間違いありません。 サーバーにライブラリをインストールした：
pear install PHP_CodeSniffer-1.3.0RC1サーバーにPEARディストリビューションがインストールされていることを前提としています。 インストール後、新しいphpcsサービスが利用可能になります。
phpcs --standard=Zend your.php少し遊んで、このソリューションがすでに多くの標準をサポートしていることを嬉しく思いました：Squiz、MySource、PHPCS、Zend、PEAR。 Zendの標準に従ってコーディングすることをやがて承認したので、私に適していました。
このライブラリのシャープ化については、
公式ドキュメントをご覧ください。日曜日4:00
彼の発見とその素早い「上昇」に触発されて、夢は後退しました。 最初のタスクは解決されましたが、コミット中にこのソリューションをバージョン管理に接続することが残っています。 PHP_CodeSnifferのドキュメントには、
SVNとの
統合の説明に特化したセクションがあります。SVNを使用したいので良かったのですが、GITを使用してgitのフックを作成することを決めました。ここで、「PEARソリューションに統合の説明がないと思いますGITで。」 そして再び、検索エンジンに目を向けると、既製のソリューション
phpcs-pre-commitが見つかりました。
git clone https://github.com/s0enke/git-hooks.gitこのフックを統合するには、gitリポジトリのhooksフォルダー（.git / hooks）に事前コミットファイルを配置する必要があります。 誰がgitフックに興味を持っていたのかは、主題の1つです。
そして、コミットの最後のチェックで、スタイルに従わないというエラーの説明が記載された表を入手しました。 phpcsエラーテーブルの表示例とその理由については説明しません。 .git / hooks / pre-commitで、使用するスタイルを指定する必要があります。
PHPCS_CODING_STANDARD=Zendまた、チェックするファイル拡張子を指定します。
PHPCS_FILE_PATTERN="\.(php|phtml)$"コミット時にエラーが発生した場合：
error: cannot run .git/hooks/pre-commit: No such file or directoryこれは、bashへのパスが正しくないことを意味し、.git / hooks / pre-commitに変更します
全体としての問題は解決されましたが、CodeSnifferによって、全員に共通する「若々しい」エラーをチェックする義務がなくなるということです。 そして主な利点は、少なくともスタイルエラーを探しているときに「若い」コードを見て、最小限のリファクタリングを実行できることです。
これで、月曜日に仕事に行って、イノベーションについて話すことができます。 これが私たちを助けるなら、誰にとってもこのソリューションの統合のためにロビーに行くことが可能になります。
月曜日、17：00
一般に、すべてが順調でしたが、私がテストすることにしたプロジェクトはかなり古く、Zend標準にいくつかの標準、たとえばラクダスタイルの変数を導入することは採算が取れませんでした。 そして、PHP_Codesnifferの独自の標準を作成する必要がありました。 スタイルチェックの説明自体は次のとおりです。
PEAR_PATH/PHP/CodeSniffer/Standards/PEAR_PATHは、サーバー上のPEARライブラリを含むフォルダーへのパスで、/ usr / local / share / pear /にあります。
独自のスタイルを作成するには、PEAR_PATH / PHP / CodeSniffer / Standards /にYOUR_STYLEフォルダーを作成します。
スタイルパックで、ruleset.xmlを作成します。 このファイルの形式については
こちらで読むことができます。私にとって便利なものだけを説明します。
エンコード要件が可能な限りZendスタイルに近いという事実により、私は単にPEAR_PATH / PHP / CodeSniffer / Standards / Zend / ruleset.xmlからコンテンツをコピーしました。
<?xml version= "1.0" ?>
<ruleset name= "Zend" >
<description>A coding standard based on an early Zend Framework coding standard. Note that this standard is out of date.</description>
<!-- Include some sniffs from all around the place -->
<rule ref = "Generic.Functions.FunctionCallArgumentSpacing" />
<rule ref = "Generic.Functions.OpeningFunctionBraceBsdAllman" />
<rule ref = "Generic.PHP.DisallowShortOpenTag" />
<rule ref = "Generic.WhiteSpace.DisallowTabIndent" />
<rule ref = "PEAR.Classes.ClassDeclaration" />
<rule ref = "PEAR.ControlStructures.ControlSignature" />
<rule ref = "PEAR.Functions.FunctionCallSignature" />
<rule ref = "PEAR.Functions.ValidDefaultValue" />
<rule ref = "PEAR.WhiteSpace.ScopeClosingBrace" />
<rule ref = "Squiz.Functions.GlobalFunction" />
<!-- Lines can be 80 chars long , show errors at 120 chars -->
<rule ref = "Generic.Files.LineLength" >
<properties>
<property name= "lineLimit" value = "120" />
<property name= "absoluteLineLimit" value = "140" />
</properties>
</rule>
<!-- Use Unix newlines -->
<rule ref = "Generic.Files.LineEndings" >
<properties>
<property name= "eolChar" value = "\n" />
</properties>
</rule>
</ruleset>
ルールセットタグで、名前を自分の名前YOUR_STYLEに置き換え、Zendで1つのルールを追加します。
<rule ref = "Zend.Debug.CodeAnalyzer" />
キャメルスタイルを無効にするには、次をコピーします：
PEAR_PATH / PHP / CodeSniffer /標準/ Zend / Sniffs / NamingConventions / PEAR_PATHのValidVariableNameSniff.php / PHP / CodeSniffer / Standards / YOUR_STYLE / Sniffs / NamingConventions / ValidVariableNameSniff.php クラスの名前をZend_Sniffs_NamingConventions_ValidVariableNameSniffからYOUR_STYLE_Sniffs_NamingConventions_ValidVariableNameSniffに変更し、追加しました：
public $isCheckCamelCaps;
そして彼は、この「フラグ」のチェックをどこにでも追加しました。 再定義する必要がある場合は、ruleset.xmlから実行できます。
<rule ref = "YOUR_STYLE.NamingConventions.ValidVariableName" >
<properties>
<property name= "isCheckCamelCaps" value = "1" />
</properties>
</rule>
火曜日、19：00
目が閉じられた多くのものが浮上しましたが、それらを整理する時が来ました！ コードスタイルの最も便利なチェックは、コードの行の長さをチェックすることでした。そのおかげで、読み取り不能な場所の多くがリファクタリングされました。
確かに、ロシア語のコメントで問題が発生しました。コード全体がUTF-8で保存され、CodeSnifferは標準のstrlenで文字列の長さをチェックし、行が2倍になったことが論理的です。 私はクラスのオーバーライドを気にしませんでしたが、これはより正確ですが、PEAR_PATH / PHP / CodeSniffer / Standards / Generic / Sniffs / Files / LineLengthSniff.phpに追加しただけです：
public $charset = 'UTF-8' ;
strlenを次のように置き換えました。
mb_strlen($lineContent, $ this ->charset)
土曜日
CodeSnifferを使った簡単な週ではありませんでした。ここに長所があります。
- コードのスタイルを確認するには時間と神経がかかります。
- 行の長さのエラーを修正するときは、コードのロジックを修正します。これは、コードの可読性と濁ったロジックのリファクタリングに有益な効果をもたらします。 また、単一行のifが良い場合と悪い場合を説明する必要がなくなります。
- コーディングスタイルのドキュメントに従う義務がなくなりました。
- すべての一般的なコーディング標準のチェックをサポートします。
短所：
- 他の人を「歴史的」プロジェクトに紹介するのは不便です。生け花を目指して数日、または数週間も過ごすことができます。
- ファイルがないとGITやSVNに対応できないため、バージョン管理を実装するのは便利ではありません。 特に数十のプロジェクトがあり、コーディングスタイルがすべての人で同じではない場合。