回答:
コーディング標準は理由があるべきです...そして、非準拠はチェックされるべきです。
ただし、すべての違反がエラーと見なされるわけではありません-すべてのコンパイル違反がそうであるとは限りません。線を引く場所は、会社とツールの決定でなければなりません。
たとえば、MISRAでは、ルールをRequired and Advisory ...と定義しています。Advisoriesでビルドを続行できるようにすることをお勧めします。
それは完全に前代未聞ではなく、試してみるだけでそれがあなたのために働くかどうかを知るでしょう。その前に実行できるいくつかの手順があります。
最初に、チームは一緒に標準を決定する必要があります。次に、ReSharperなどのツールを使用して、標準に準拠していないかどうかを開発者に通知する必要があります。すべてのタスクでピアレビューを行うと、さらに役立ちます。
これらの手順を実行した後、コーディング標準チェックをCIサーバーに配置することを検討できます。ただし、コーディング標準に従わないためにビルドを中断するのが賢明な場合は、まだ検討する必要があります。リスクは、多くの壊れたビルドがあり、壊れたビルドの意味を薄める可能性があることです。
ビルドを中断する代わりに、ツールを実行してレポートを作成することができます。コーディング標準違反が増加しているように思われる場合は、チームをまとめて、なぜそれが起こっているのかを把握できます。
コーディング標準/スタイルは、静的分析ツール（例：PMD、StyleCop / FxCop）を実行し、標準に従っていない場合はビルドに失敗する継続的統合サーバーによって実施されるべきですか？
これらの継続的な統合チェックは、非常に高速である必要があります。大幅な遅延は、プログラマーがコミットして、結果を待っている間に思考プロセスを追跡できなくなることを意味します。長くすると、彼らはコミットしてコーヒーを飲んだり、一部のスポーツチームの最新のパフォーマンスについてオフィスの仲間とチャットしたりします。これらの遅延は非常に非生産的です。いくつかのことは、ナイトリービルドまたはコードレビューに任せるのが最適です。
ビルドを失敗させるためにどの種類のルールを使用すべきではありませんか？
主観的なもの、そもそも。「コードは自己文書化または十分にコメントされる」ルールをどのように施行しますか？「マジックナンバーなし」ルール？これらは、コードレビューに委ねるのが最適です。
別のカテゴリは、すでに免除が認められている規則への違反です。かなりの規模のコードベースがある場合、標準に違反することがまさに正しいことであるコードのチャンクが必ず存在します。
ソフトウェア品質改善計画の一環として、最近、一連のコードスニフをコーディングして、ビルドプロセスに統合しました。
私たちはたくさんのビルドを行います。PHPアプリケーションなので、実際のコンパイルはありません。そのため、ビルドは実際には単体テスト/静的分析/ランナーであり、これに数サイクル費やすことができます。
いくつかのコード品質の問題と、多くの問題のあるレガシーコードがありました。
コミットが失敗しない場合は無視されることに基づいて開始し、「望ましい」コーディング標準に対するコミットの確認を開始し、標準を満たさないエラーでコミットを失敗し始めました。
メンテナンスの中断、レガシーコンポーネントの最も単純な修正でさえ、開発者が大量のソースを再フォーマットする必要があり、ビルドは頻繁に破損しました。言うまでもなく、エラーを警告に変更しましたが、今では無視され、「ほとんど」意味がありません。
だから私はこれを言うだろう（ハードな経験から学んだ）。
コードベースの標準が、開発者がすぐに大量のコードを再フォーマットする必要がないことを強制する標準に十分近いことを確認してください。または..努力の増加に備え、期待しています。
巨大な納品要件を持つ小さなチームであるため、チームを巨大なリファクタリング操作に切り替える余裕はありませんでした。現在、当社のコーディング標準の大部分は手動でレビューされており、レガシーは継続的な改善計画の一環として書き直されています。
警告が「ほとんど」無意味であると言ったとき、私たちは今、改善を示し続けるべきkpiを測定できる統計を記録するためにそれらを使用しています。
コードスニッフィングを再度実施するとき、我々は軽く始め、標準が実施されるまで一度にいくつかのスニフを導入します。
それは最終的な目標と戦略に依存します。
CIサーバーで言及されているすべての標準を強制することは、非常に有利に思えるかもしれません。ただし、サーバーへのコミットごとに行われる場合、大規模な（6人以上の開発者）開発チームにとっては実用的ではない場合があります。コミット後にサーバーが応答するのを待つことは、長い遅延であってはなりません。潜在的にダウンタイムを引き起こす可能性があります。
ただし、コード（実際の変更セット）に依存関係の問題があるか、コンパイルされない場合、コミットをブロックすることは完全に合法です。ただし、コードレイアウトといくつかの命名規則のためにコードが失敗することは、あまりにも深刻であり、CIサーバーコミットルールの重要な制限ではない場合があります。
ただし、イブニングビルド中に適用する場合、有用なルールになる可能性が非常に高くなります。
さらに、リファクタリングツールは、開発者によるResharperまたはJustCodeの使用など、標準の実装と学習に役立ちます。