PHP CodeSniffer？Code Standards Enforcement in General？
コードベースの品質を向上させるために、継続的インテグレーションサーバーに PHP CodeSniffer をセットアップするというアイデアに手を出しました。ドキュメントを読んだ後、コーディング標準を標準化し、実施するというアイデアに非常に興奮しています。しかし、私たちの製品の実際の改善については疑問に思っています。スニファーは定義されたコーディング標準に対する違反のみを検出することをよく知っていますが、クリーンで一貫性のあるコードベースはどのような利点を提供しますか？ PEAR規格に準拠するように100k +行のコードを使用してプロジェクトをリファクタリングすることは、余分な作業の価値がありますか？
PHP CodeSnifferまたはcode-smell全般に精通していない人のために、出力例を次に示します。
ファイル：/path/to/code/myfile.php
2行に影響する5エラーが見つかりました
-
2 |エラー|ファイルのドキュメントコメントがありません
20 |エラー| PHPキーワードは小文字である必要があります。「false」が必要ですが、「FALSE」が見つかりました
47 |エラー|行が正しくインデントされていません。 4つのスペースが必要ですが、1つ見つかりました
51 |エラー|関数のドキュメントコメントがありません
88 |エラー|行が正しくインデントされていません。 9つのスペースが必要ですが、6つ見つかりました
厳密に言えば、ユーザー/クライアントは、標準に準拠するようにリファクタリングされた製品の違いに気付かないでしょうが、他の隠れた利点があるかどうか疑問に思っています
現在、私たちのコードは決してだらしないものであり、ほとんどの場合、 Pear's Coding Standards から派生した独自の個人標準に従うようにしていますが、訓練された目で違いを見つけることができます。
私の質問は、製品の品質をどれだけ改善するかです。それからどのような潜在的な利点が生じましたか？
私たちの製品を一連の標準に近づけたいという願望に、私はただ強迫観念しているのでしょうか？それは価値があるでしょうか？その場合、コードスニファーを実装し、検出された後続の違反を修正するために、どのような戦略を使用しましたか？
まず、私はPHP_CodeSnifferのメンテナーなので、この分野には明らかに偏見があります。しかし、私は10年間でPHP devとしていくつかの大きなコードベースに取り組んできたので、コーディング標準が良いことの具体的な理由をもたらすことができることを望みます。このトピックに関するブログシリーズですが、ツールが私のために解決した問題を理解できるように、PHP_CodeSnifferがどのように生まれたのかについて少しお話しします。
私はいくつかの大きなCMSプロジェクトに取り組んできました。最初のものには、背後に大量のコードがあり、比較的小さな開発チームがありました。基準はありませんでした。しかし、実際の問題はありませんでした。チームは小さく、かなり長い間一緒にいました。私たちはお互いに慣れました。
次に、新しいCMSを構築しました。私たちはほんの数人の開発者から始めました。そのとき、私は2人の開発者からなるチームの一員でした。繰り返しますが、コーディング標準は問題を引き起こしませんでした。私と他の開発者は同じ背景から来て、私たちが従ったいくつかのガイドラインをすでに確立していました。当時はPHPCSは必要ありませんでした。
しかし、そのチームは一度に開発者を育て、最終的には12人のフルタイムの開発者に到達し、かなりの数が出入りしました。古いCMSから来た人もいれば、社外から来た人もいました。すべてが異なる背景と開発への異なるアプローチを持っていました。スタイルが非常に異なっていたため、誰がどのコードを書いたかは明らかでした。複雑なものに取り組むときは、コードを見るのに慣れていた方法ではなかったため、最初にスタイルに適応する必要があります。シェークスピアを初めて読むようなものです。自然なペースで読むには、それに慣れる必要があります。
開発者にとって、停止して別のコーディングスタイルを見つけ出す余分な時間は、純粋に無駄な時間です。間隔、インデント、ブラケットの位置で動けなくなっている間に、アイデアが抜け落ちてしまう可能性があります。結局のところ、これらのことは重要ではありません。ただし、開発者にフローを中断させている場合、それらは重要です。そのため、開発者が邪魔にならないようにし、開発者が最善を尽くせるようにする方法が必要でした。
同時に、JavaScriptをさらに掘り下げていました。スタイルが一般に窓から投げ出された新しい言語。コードはサンプルサイトからコピー/貼り付けされ、一緒にマッシュされました。新しい言語で複雑なコードを開発することを学ぶとき、JSをPHPに似せる方法を見つけることは理にかなっています。後で最小化できますが、フローを維持するために、言語をすばやく切り替えることができる必要がありました。
そのため、PHP_CodeSnifferはそれを行うために生まれました。開発者が同じコーディングスタイルで作業し、フォーマットやその他のフレームベイトの問題を完全に回避できるようにします。これにより、JSをPHPのように扱うことができます。翻訳されていない文字列や適切なクラスインクルージョンコードを使用していない開発者のような製品固有の匂いを検出するために使用します。これは、IEを殺すJSコンマが残されていないことを確認するような言語特有の匂いのためです。あなたは、あなたが望むものにそれを使用することができます。 XMLルールセットファイル を使用して一緒に作成することもできます。独自のコードを作成することもできます。サードパーティのツールを統合して、静的コード分析のワンストップショップにすることもできます。コードは好きな匂いがします。
PHP_CodeSnifferは、他の開発ツールと同様に機能します。あなたはそれのために働きません。気にしないエラーが多すぎる場合は、標準をカスタマイズして不要なものを削除するか、エラーを警告に変えてください。しかし、私の話があなたが経験している、または将来経験するかもしれないもののように思える場合、PHP_CodeSnifferをよく見て、それがあなたを助けることができるかどうか確かめる価値があります。
これが、あなたや他の人々が、コーディング標準が一部のプロジェクトや開発者にとって本当に重要である理由を理解するのに役立つことを願っています。詳細についてではありません。開発者が焦点を失う原因となるもののリストからコーディングスタイルを削除することです。
コーディングスタイルの規則を用意することは、開発者が記述していないコードで作業するときに、異なるスタイルで記述されたコードに気を取られないようにするのに役立つためです。コードベースが表面的にきれいになります。それを自動化できれば素晴らしいことですが、通常、準拠するために長い時間をかける必要はありません（現在のスタイルがterribleでない限り）。すでに十分な標準がある場合は、それに固執します。
ただし、コードの匂いは何かが異なります。コードのより深い問題を示す可能性のある（一連の）症状です。例としては、循環的複雑さ、長いメソッド名、大きなクラス、説明のない名前、重複コードなどがあります。これは、コードの保守性を徹底的に損なう可能性があるため、通常ははるかに問題です。これらの問題を確実に解決する必要があります。
PHP CodeSnifferは、コードの匂いではなく、主にスタイル規則をチェックするために開発されたようです。これを使用して、スタイルの規則を強制するのに役立てることができれば、素晴らしいです。ただし、コードベースが実質的にbetterにならないことに注意してください。あなたはそれを達成するために手動のレビューをしたいと思うでしょう。
your current標準に準拠しているかどうかを確認するためにそれを使用する場合、それは可能と思われる、「あなたのコーディング標準に同意しない！PHP_CodeSniffer私自身を強制しますか？」 FAQで 。
CodeSnifferを福音化する人々の中で私を数えてください。長年にわたって非常に懐疑的でしたが、現在、私は取り組んでいるすべてのプロジェクトでそれを使用しています。どうして？
グレース・ホッパーやアンドリュー・タネンバウムが有名なように、
標準のすばらしいところは、選択できるものが非常に多いことです。
同様に、独自のコーディング標準を作成することは、ほとんど常にBad Idea™です。すべてのコードをカバーするのに十分な包括的なものを作成することはhardであり、さらに重要なことは、あなたの標準を「改善」しようとするコードを維持する次の人の好みではない彼の長年のコーディングスタイルに合うように。 ZendかPEARかKohanaかJoeBobBriggsAndHisFifthCousinかどうかにかかわらず、標準外の適切なを採用すると、---ではなくcontentに集中することができます。 formatting。さらに良いのは、PHP CodeSnifferのようなツールは、標準の "新鮮なもの"をサポートするか、以前に行ったことのある人がほぼ確実にサポートを追加として実装したことです。オン。
コーディング標準と、その標準に準拠していない既存のコードを混在させると、2つの単純な補完的なルールを採用しない限り、適合します。
--ignoreコマンドラインオプションまたは同等の構成ファイル設定を使用して、コーディング標準の採用前のファイルをチェック対象から除外します。ただし、ソースファイルのany partを変更する場合は、選択した標準に準拠するようにファイル全体を更新してください。
新しいブログ投稿を書いた この種のことについて。
人間の判断を必要とするケースはたくさんありますが、CodeSnifferにはそれがありません。
一貫した括弧、インデントによりコードが改善されます。関数呼び出しのカンマの後にスペースがありませんか？おそらく許されますが、CodeSnifferによれば[〜＃〜] error [〜＃〜]です。
私見では、CSによって報告されるエラーが多すぎます。きちんとしたコードを持っているように見えるプロジェクトでさえ、CS問題の数千に簡単に遭遇する可能性があります。特に実際の問題と強迫観念のナンセンスが混在している場合、特に[〜＃〜] errors [〜＃〜] 。
完全に表面的な空白やコメントの変更（1行のisAlpha関数には実際に8行が必要です）よりも、CSを無視し、コードの実際の改善（設計、アルゴリズムの観点）に時間をかける方が良いかもしれませんコメント？はい、CSに尋ねた場合）。
CSは、簡単に研磨ツールになりすぎます。
これは間違いなく良いことです。 SVNフックから実行するので、すべてのコードはコミットする前に社内標準（PEARからの変更）に合格する必要があります（これは私がこれまでに行った最良の決定の1つでした）。
もちろん、これは新しいプロジェクトに最適に機能します。新しいプロジェクトでは、新しい標準に変換するためのレガシーコードがロードされていません。これを回避する1つの方法は、コードスニファーへの新しい追加のみを実行し、変更を無視するようにSVNプリコミットフックを変更することです。これを行うには、次の行を追加します。
$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0
これは、解析する新しいPHPコードがない場合、フックスクリプトを終了します。したがって、すべての新しいファイルは標準に従う必要があり、レガシーコードを標準に引き上げることができます。自分の時間。
EclipseまたはZend IDEを使用している場合、標準の尊重を低コストにする自動ツールの恩恵を受けることができます。HudsonやPHPUndercontrolなどの継続的統合ツールを使用することもできます。
- PDTはPHP用のクールなエディターです
- PDT-Toolsは、自動フォーマットツールを備えたPDTのプラグインです。
- DTLK（Dynamic Toolkit Library）を使用して、ファイルをチェックするためのいくつかの外部スクリプトを起動できます。
また、 PHP Checkstyle を確認することもできます。これは設定が簡単だと思います（免責事項：取り組んできました）
他のいくつかのツールは、Webサイトの「ドキュメント」ページにリストされています。
CodeSnifferは実装するのに最適ですが、使用方法を知っておく必要があります。外部プロジェクトに作業を送信するために特定のコーディング標準に従う必要がない限り、独自のコーディング標準を完全に定義できます。
PHP CodeSnifferを使用すると、これを非常に簡単に行うことができます。これは、独自のコーディング標準定義に含めることができる単一のコードスニフがすでに多数あり、それらを最初から記述する必要がないためです。既存のCodesniffersの可能性を探りながら、必要に応じて、既存のスニフまたは自分で1つのスニフの拡張機能を作成することになります。
CodeSnifferから始めたい場合、最初のステップは、現在のコーディング標準に完全に似ているスニフのセットを取得し、結果のエラーと警告を確認することです。事前定義された標準のいずれかを適用しないでください。修正すると、多くのエラーが発生し、利益が少なくなります。たとえば、PHPDocを使用してドキュメントを生成しない場合、PHPDocタグとコメントの欠落に関するすべてのコードスニファーエラーを解決することはできません。
PEAR PEAR/PECLを介したパブリック配布用のパッケージを提供していますか？その場合、おそらくPEAR規約に固執したいでしょう。
そうでなければ、大きなリファクタリングの価値があるとは思えません。最大のことは、あなたのチームのコーディング標準に同意することです... PEARの標準である必要はありません...何らかの標準規約が適用されていることを確認してください。
たとえば、私はのファンです
function foo () {
format vs. PEAR standard ..
function foo ()
{
結論として、特にPECLにパッケージを配置しない場合、大量の作業が必要になる場合でも、標準に準拠することについてあまり心配する必要はありません。