私は現在、大規模なプロジェクトに取り組んでいます。そこでは、多くの開発者が時間をかけて作業し、コードはひどいものでした。多くのリファクタリングを行った後、コードに問題がないポイントに到達しました。今、私は「ok」が何を意味するのかを考えています-おそらく誰にとっても何か違うものです。
「OK」を指定することは可能だと思いますか？重要なことは何ですか？NDependメトリック？テストカバレッジ？コメント？コーディングスタイル？ドキュメンテーション？
コーディングスタイルやコメントについては、すでに多くのトピックがあることを私は知っています（たとえばここ）。この質問は、どのような事実が重要であるかについてです。
重要なプロジェクトでは、コーディングガイドライン（スタイル、コメントなど）と、それらが守られているかどうかを知るためのメトリックを用意する必要があると思います。あなたが概説したリストは非常に良いスタートです。
あなたは2つの異なるものを混ぜ合わせています。
コーディングスタイルについて話しますが、テストカバレッジ、メトリックなどについて言及します。
コーディングスタイルは確かに指定できます。すべての要件ドキュメントには、「コードの保守と一貫性の目的で、このプロジェクトはこれらのコーディングスタイルと標準に従う」と記載されている必要があります。
ただし、一般的に、ほとんどのプロジェクトでは、「優れた業界慣行」と「プロジェクト全体で一貫したコーディングスタイル」が必要であり、実際の定義と実装は開発者に任されています。
ただし、議論している他の問題、リファクタリング、テスト、カバレッジなどを必要とする不正なコード（LINTと静的分析もスローします）は、明示的に指定して要求する必要があります。それらを仕様から除外する理由はありません-それらは、どのタイプのコーディングエラー（または、スタイルと不良コードの間のあいまいな線に乗る、どのタイプのコーディングパターンがバグのあるコードを生成する可能性が高いか）を示すハードメトリックです任意のコードで、それがどれだけうまく機能し、テストがどれだけ正しく動作を示しているか。
大規模なプロジェクトでは、顧客は主任開発者と一緒に座り、たとえばLINT構成を調べて、ニーズを満たし、軽薄なエラーが開発を遅らせていないことを確認します。
つまり、要するに、そうです、これはすべて、重要なプロジェクトに指定できます（そして、そうすべきです）。
-アダム
あなたは正しいです、大丈夫は誰にとっても異なります。とはいえ、期待値を定義したら、それを今後も維持するための最良の方法は、頻繁なコードレビューを行うことです。
人々、特にプロジェクトの新しい人々は、常に独自のスタイルをもたらします。コードレビューは、コードのアンドロギン化に役立ちます。
コードやツールとは関係のないプロジェクトの品質を向上させるものはたくさんあります。
要件管理。要件に品質管理を適用するためのプロセスがあります。それらは意味がありますか？誰がそれを求めましたか？彼らはこれらの要求をするのにふさわしい人々ですか。
テストデザイン。実装ではなく、要件に従ってテストを構築します。コーダーにテストをさせないでください！
すべてをテストする-毎回。すべてのリリースについて完全なテストサイクルを実行します。マイナーリリースなどはありません。
私の経験では、コードメトリックやコード標準などは実際には機能しません。デッドビートコーダーが誰であるかがわかります。それらを識別するための正式なプロセスは必要ありません。
品質と出力を改善するために実際に機能する1つの手法は、コードレビューです。3つのリソースで1日を費やして、5日間の作業を確認するには、ある程度の規律とバックボーンが必要です。しかし、潜在的な問題をそれほど徹底的に明らかにするものは何もありません。そして、誰かが来週それを批判することを知っているなら、ダメな人々はただより良いコードを書くだけです。
ok/goodコードの属性と言えるものはたくさんあります。
このトピックに関するSOに関する他のスレッドもいくつかあります...
ある種のガイドライン (スタイルはコンテンツの IMO ほど重要ではありません)。例: ベスト パターン/プラクティスですが、より重要なのはコード レビューです。
StyleCop ... また、FxCop ...
チームはスタイルを絶対に標準化する必要があります。個人的な選択の余地はありますが、チームは絶対にスタイルを標準化する必要があります。コードはより読みやすく、より保守しやすく、より簡単にレビューできます。