54

コードベースの品質を向上させるために、継続的インテグレーション サーバーにPHP CodeSnifferをセットアップするというアイデアに手を出しています。ドキュメントを読んだ後、コーディング標準を標準化して強制するというアイデアに非常に興奮しています。しかし、私たちの製品の実際の改善については疑問に思っています. スニファーが定義されたコーディング標準への違反のみを検出することはよく知っていますが、クリーンで一貫性のあるコードベースにはどのような利点がありますか? PEAR 標準に準拠するために 10 万行以上のコードを含むプロジェクトをリファクタリングするのに余分な作業をする価値はありますか?

PHP CodeSniffer や code-smell に慣れていない方のために、出力例を次に示します。

ファイル: /path/to/code/myfile.php
FOUND 5 ERROR(S) AFFECTING 2 LINE(S)
--
2 | エラー | ファイル ドキュメント コメントがありません
20 | エラー | PHP キーワードは小文字にする必要があります。"false" と予想されていましたが、"FALSE" が見つかりました
47 | エラー | 行が正しくインデントされていません。4 つのスペースが必要でしたが、1
51 |見つかりました。エラー | 関数ドキュメントのコメントがありません
88 | エラー | 行が正しくインデントされていません。9 個のスペースが必要でしたが、6 個見つかりました

厳密に言えば、ユーザー/クライアントは、標準に準拠するようにリファクタリングされた製品の違いに気付かないでしょうが、他に隠れた利点があるかどうか疑問に思っています

現在、私たちのコードは決してずさんではなく、Pear's Coding Standardsから派生した独自の基準に従うように努めていますが、訓練された目で違いを見つけることができます。

だから私の質問は、それらが製品の品質をどれだけ改善するかということです. それによってどのような潜在的な利益が生じましたか？

製品を一連の基準に近づけたいという欲求に、強迫観念を抱いているだけですか? それは価値があるでしょうか？もしそうなら、コードスニファーを実装し、検出されたその後の違反を修正するためにどのような戦略を使用しましたか?

4

8 に答える 8

104

まず、私は PHP_CodeSniffer のメンテナーなので、この分野では明らかに偏見があります。しかし、私は PHP 開発者としての 10 年間でいくつかの大きなコード ベースにも取り組んできました。そのため、コーディング標準が優れている理由について具体的な理由を説明できればと思っています。このトピックについてはブログ シリーズを書くこともできますが、PHP_CodeSniffer によって解決された問題を理解できるように、PHP_CodeSniffer がどのように生まれたかについて少しだけお話しします。

私はいくつかの大きな CMS プロジェクトに携わってきました。1 つ目は、背後に大量のコードがあり、開発チームは比較的小規模でした。私たちには基準がありませんでした。しかし、実際の問題はありませんでした。チームは小さく、かなり長い間一緒にいました。私たちはお互いに慣れました。

次に、新しい CMS を構築しました。ほんの数人の開発者で新たに始めました。当時、私はたった 2 人の開発者のチームの一員でした。繰り返しになりますが、コーディング標準によって問題が発生することはありませんでした。私と他の開発者は同じバックグラウンドを持っており、従うべきいくつかのガイドラインをすでに確立していました。当時は PHPCS は必要ありませんでした。

しかし、そのチームは一度に開発者を増やし、最終的には 12 人のフルタイムの開発者に達し、かなりの数の開発者が行き来しました。一部は古い CMS からのもので、一部は社外からのものでした。全員が異なるバックグラウンドを持ち、開発への異なるアプローチを持っていました。スタイルが非常に異なるため、誰がどのコードを書いたかは明らかでした。複雑なことに取り組むときはいつでも、最初に彼らのスタイルに順応する必要がありました。それは、コードを見るのに慣れていなかったからです。初めてシェイクスピアを読むようなものです。自然なペースで読むには、慣れる必要があります。

開発者にとって、立ち止まって別のコーディング スタイルを見つけなければならない余分な時間は、純粋に無駄な時間です。間隔、インデント、およびブラケットの位置に行き詰まっている間に、アイデアがすり抜けてしまう可能性があります。結局のところ、これらのことは問題ではありません。しかし、開発者がフローを壊す原因となっている場合、それらは非常に重要です。そのため、開発者を邪魔にならないようにし、開発者が最も得意とすることをできるようにする方法が必要でした。

同時に、私たちは JavaScript をさらに掘り下げていました。スタイルが一般的に窓の外に投げ出された新しい言語。コードはサンプル サイトからコピー アンド ペーストし、マッシュアップしたものです。新しい言語で複雑なコードを開発することを学ぶとき、JS を PHP に似たものにする方法を見つけることは理にかなっています。後で最小化できますが、フローを維持するために、言語をすばやく切り替える必要がありました。

そのため、PHP_CodeSniffer はそれを行うために生まれました。これは、開発者が同じコーディング スタイルに取り組み、書式設定やその他の炎上問題を完全に解決するのに役立ちます。これにより、JS を PHP のようにある程度扱うことができます。これを使用して、翻訳されていない文字列や開発者が適切なクラス インクルード コードを使用していないなど、製品固有のにおいを検出します。また、IE を強制終了する JS コンマが残らないようにするなど、言語固有の臭いにも使用します。何にでもお使いいただけます。XML ルールセット ファイルを使用して簡単にマージできる大量のスニフが付属しています。自分で書くこともできます。サードパーティのツールを統合して、静的コード分析のワンストップ ショップにすることができます。標準やコードの匂いについては、好きなだけ真剣に考えることができます。

PHP_CodeSniffer は、他の開発ツールと同様に機能するはずです。あなたはそれのために働いていません。気にしないエラーが多すぎる場合は、標準をカスタマイズして不要なものを削除するか、エラーを警告に変えてください。しかし、私の話があなたが経験している、または将来経験する可能性のあるものであると思われる場合は、PHP_CodeSniffer を詳しく調べて、それが役立つかどうかを確認してください。

一部のプロジェクトや開発者にとってコーディング標準が本当に重要である理由を理解するのに役立つことを願っています。詳細についてではありません。それは、開発者が集中力を失う原因となるもののリストからコーディング スタイルを削除することです。

于 2011-05-12T22:41:44.790 に答える
32

コーディング スタイルの規則を定めることは、開発者が作成していないコードで作業するときに、異なるスタイルで記述されたコードに気を取られるのを防ぐのに役立つため、良い考えです。コードベースが表面的にきれいになります。自動化できれば素晴らしいことですが、通常は準拠するために多大な時間を費やす必要はありません (現在のスタイルがひどい場合を除きます)。すでに十分な基準がある場合は、それに固執してください。

ただし、コードの臭いは別のものです。それは、コードのより深い問題を示している可能性がある (一連の) 症状です。例としては、循環的複雑度、長いメソッド名、大きなクラス、説明のつかない名前、重複したコードなどがあります。これは通常、コードの保守性を完全に損なう可能性があるため、はるかに問題になります。これらの問題を確実に解決する必要があります。

PHP CodeSniffer は、コードの匂いではなく、主にスタイル規則をチェックするために開発されたようです。それを使用してスタイルの規則を強制することができれば、素晴らしいことです。ただし、コード ベースが大幅に改善されるわけではないことに注意してください。それを達成するには、手動でレビューを行う必要があります。

現在の標準に準拠しているかどうかを確認するためにそれを使用したい場合は、それが可能であると思われるため、「私はあなたのコーディング標準に同意しません! PHP_CodeSniffer に独自の標準を適用させることはできますか?」という質問への回答を参照してください。よくある質問で。

于 2009-06-11T18:06:01.817 に答える
11

CodeSniffer を伝道する人々の中に私を数えてください。何年も非常に懐疑的だった後、私は今、取り組んでいるすべてのプロジェクトでそれを使用しています. なんで？

グレース・ホッパーやアンドリュー・タネンバウムが有名に言ったように、

標準のすばらしいところは、選択できるものが非常に多いことです。

同様に、独自のコーディング標準を作成することは、ほとんどの場合、悪い考えです。すべてのコードをカバーするのに十分な包括的なものを作成することは困難であり、さらに重要なことは、次の人があなたのコードを保守することを好まないということです。コーディング スタイルを保持します。Zend であれ、PEAR であれ、Kohana であれ、JoeBobBriggsAndHisFifthCousin であれ、適切な外部標準を採用することで、フォーマットではなくコンテンツに集中することができます。さらに良いことに、PHP CodeSniffer のようなツールは、標準の「缶から出してすぐに使える」ものをサポートしているか、以前に行ったことのある人はほぼ確実にサポートをアドオンとして実装しています。

2 つの単純で補完的な規則を採用しない限り、コーディング標準とその標準に従って書かれていない既存のコードを混在させると、適合します。

--ignoreコマンドラインオプションまたは同等の構成ファイル設定を使用して、コーディング標準の採用より前のファイルをチェックから除外し ます。ただし、ソース ファイルの一部を変更する場合は、選択した標準に準拠するようにファイル全体を更新してください。

この種のことについて、新しいブログ記事を書きました。

于 2010-07-28T14:56:07.480 に答える
6

人間の判断が必要なケースはたくさんありますが、CodeSniffer にはそれがありません。

一貫したブラケット、インデントによりコードが改善されます。関数呼び出しのカンマの後にスペースがありませんか? おそらく許されるかもしれませんが、CodeSniffer によるとそれはERRORです。

私見では、CS によって報告されるエラーが多すぎます。きちんとしたコードを持っているように見えるプロジェクトでさえ、何千もの CS の問題に簡単に遭遇する可能性があります。これらすべての問題を解決するのはすぐに面倒になり、ほとんど不可能になります。特に、実際の問題と強迫観念的なナンセンスが混在している場合は、どちらも同じようにエラーとしてマークされることがよくあります。

CS を無視して、コードの実際の改善 (設計、アルゴリズムの観点から) に時間を費やした方が、完全に表面的な空白やコメントの変更 (1 行isAlphaの関数に 8 行のコメントが本当に必要なのか?) よりも良いかもしれません。 CSに聞いてください）。

CS はあまりにも簡単に糞を磨くツールになる可能性があります。

于 2009-06-12T22:13:40.013 に答える
3

これは間違いなく良いことです。すべてのコードがコミットされる前に自社標準 (PEAR からの変更) に合格する必要があるように、私たちは SVN フックから実行します (これは私がこれまでに下した最良の決定の 1 つです)。

もちろん、これは、新しい標準に変換するための大量のレガシー コードがない新しいプロジェクトに最適です。これを回避する 1 つの方法は、SVN pre-commit フックを変更して、codesniffer への新しい追加のみを実行し、変更を無視することです。これを行うには、次の行を追加します。

$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0

解析する新しい PHP コードがない場合、これによりフック スクリプトが終了します。したがって、すべての新しいファイルは標準に従う必要があり、自分の時間でレガシー コードを標準に合わせることができます。

于 2009-08-26T22:40:44.740 に答える
3

Eclipse または Zend IDE を使用している場合は、標準を尊重するコストを削減する自動ツールの恩恵を受けることができます。Hudson や PHPUndercontrol などの継続的インテグレーション ツールを使用することもできます。

  • PDT は PHP 用のクールなエディターです
  • PDT-Tools は、自動書式設定ツールを備えた PDT 用のプラグインです。
  • DTLK (Dynamic Toolkit Library) を使用して、いくつかの外部スクリプトを起動してファイルをチェックできます。

設定が簡単だと思うPHP Checkstyleもご覧ください（免責事項：私はそれに取り組んできました）

他のいくつかのツールは、Web サイトの「ドキュメント」ページにリストされています。

于 2010-06-01T12:06:52.877 に答える
1

CodeSniffer は実装するのに最適ですが、その使用方法を知っておく必要があります。作業を外部プロジェクトに提出するために特定のコーディング標準に準拠する必要がない限り、独自のコーディング標準を自由に完全に定義できます。

PHP CodeSniffer を使用すると、これを非常に簡単に行うことができます。独自のコーディング標準定義に含めることができ、最初から作成する必要がない単一のコード スニフが既に多数あるためです。既存の Codesniffer の可能性を探っているうちに、必要に応じて、既存の sniff の拡張機能または 1 つの sniff を自分で作成することになるかもしれません。

CodeSniffer を使い始める場合、最初のステップは、現在のコーディング標準に完全に似ている一連のスニフを取得し、結果のエラーと警告を確認することです。事前定義された標準のいずれかを適用しないでください。修正した場合のメリットがほとんどなく、エラーが多すぎる可能性が高いためです。たとえば、PHPDoc を使用してドキュメントを生成しない場合、PHPDoc タグとコメントの欠落に関するすべてのコードスニッファー エラーを解決しても意味がありません。

于 2010-06-07T11:32:11.253 に答える
0

PEAR/PECL による一般配布用の PEAR パッケージを提供していますか? もしそうなら、おそらく PEAR の規約に固執したいと思うでしょう。

そうでなければ、大きなリファクタリングを行う価値があるとは思えません。最も重要なことは、チームのコーディング標準に同意することです... PEAR の標準である必要はありません... 強制される標準的な規則があることを確認してください。

たとえば、私はのファンです

function foo () {

形式と PEAR 標準..

function foo ()
{

結論として、特にパッケージを PECL に入れていない場合は、彼らの標準に準拠することが膨大な作業になる場合でも、あまり心配する必要はありません。

于 2009-06-11T18:14:45.447 に答える