28

現在進行中のプロジェクトの 1 つで FxCop の使用を開始する予定です。しかし、利用可能なすべてのルールを選択して試してみると、コードに多くの変更を加える必要があるようです。「チーム メンバー」であるため、命名規則の変更など、これらの変更をすぐに開始することはできません。とにかく、最小限のルール セットで FxCop の使用を開始し、ルール セットを徐々に増やしていきます。私が従うべきFxCopルールが必要ないくつかを教えてください。または、より良いアプローチを提案していますか？

注: 私のコードのほとんどは C# です。

4

10 に答える 10

12

最も重要なコードについて:

信じられないかもしれませんが、FxCop はより良いコードの書き方について多くのことを教えてくれます...素晴らしいツールです! したがって、私たちにとって、すべてのルールは等しく重要です。

于 2008-09-27T08:58:13.627 に答える
8

私の意見では、次のことを行います。

新しいプロジェクトでは、すべての FxCop ルールに従います。すべてがあなたのプロジェクトにとって意味があるわけではないので、それらのいくつかを無効にしたいかもしれません。既存のプロジェクトの場合、最小限のセットとして次のカテゴリのルールに従います。

  • グローバリゼーション
  • 相互運用性
  • 安全
  • パフォーマンス
  • 携帯性

これらは通常、他のカテゴリと比較して、既存のプロジェクトでのルール違反はごくわずかですが、アプリケーションの品質を向上させる可能性があります。これらのルールが明確になったら、次のカテゴリを修正してみてください。

  • デザイン
  • 使用法

これらにより、違反に関係するバグを見つけやすくなりますが、既存のコードに大量の違反が発生することになります。

常に違反をレベル/修正カテゴリ別に並べ替え、重要なものから始めます。ここでは、警告をスキップします。

ご存じない場合は、Microsoft から入手できる StyleCop もあり、ソース レベルでコードをチェックします。インストール中に MSBuild 統合を有効にしてください。

于 2008-09-27T08:38:07.060 に答える
4

一部のルールは、バグやリークを回避します。

  • 一般的な例外の種類をキャッチしない (これが私たちにとって最良のルールかもしれません。場合によっては、強制するのが簡単な場合と難しい場合があります)
  • NaN を正しくテストする (強制しやすい)
  • 使い捨て可能なフィールドは破棄する必要があります（強制するのは非常に簡単です）
  • Dispose は base dispose を呼び出す必要があります (強制するのは非常に簡単です)
  • 使い捨て型はファイナライザーを宣言する必要があります (強制するのは非常に簡単です)

設計を改善するのに役立つものもありますが、注意してください。中央の API が影響を受けると、大きなリファクタリングにつながる可能性があります。私たちが好き

  • コレクション プロパティは読み取り専用にする必要があります (この場合、強制するのは困難です)
  • ジェネリック リストを公開しない
  • メンバーは特定の具象型を公開すべきではありません
  • 使用パラメータの見直し (API を簡単に改善)

私たちのプロジェクトの誰かがパフォーマンス ルールを試しましたが、改善はありませんでした。(実際には、これらのルールはマイクロ最適化に関するものであり、マイクロ最適化が必要であることを示すボトルネックの識別がない場合、結果は得られません)。これらから始めないことをお勧めします。

于 2010-01-27T10:56:08.280 に答える
2

一度に1つのルールをオンにします。報告された警告を修正または除外してから、次の警告から始めてください。

于 2008-12-18T17:14:51.737 に答える
2

FxCop の代わりに、C# LINQ クエリ (つまり、CQLinq) でコード ルールを記述できるツール NDepend を使用することもできます。免責事項: 私はツールの開発者の 1 人です。

デフォルトで200 以上の Code Rulesが提案されています。よく知られているC# LINQ 構文のおかげで、既存のルールのカスタマイズや独自のルールの作成は簡単です。

NDepend はいくつかのコード ルールで FxCop と重複しますが、多くの独自のコード ルールを提案します。従わなければならないものとして分類するいくつかのルールを次に示します。

ルールは、生成された HTML+javascript レポートで、Visual Studioとビルド プロセス時にライブで検証できることに注意してください。

于 2008-12-18T16:52:06.070 に答える
2

最小限の fxcop とコード分析 (VS2010 Premium または Ultimate を使用している場合) は次のとおりです。

于 2010-12-14T15:12:32.987 に答える
1

私たちのプロセスでは、すべてのルールを有効にしてから、レビュー プロセスの一環として抑制を正当化する必要があります。多くの場合、締め切りやエラーで発生したエラーに関して、時間効率の良い方法でエラーを修正することは不可能です (これは、特にアーキテクチャがリフレクションを介してプラグインを処理する場合に発生することがあります)。

また、例外に渡される文字列をグローバル化したくなかったため、グローバリゼーション用のカスタム ルールを作成して、既存のルールを置き換えました。

一般的に、すべてのルールを順守するのが最善だと思います。私の現在のホーム プロジェクトには、4 つのビルド構成があります。1 つは CODE_ANALYSIS 定義を指定するセットで、もう 1 つは指定しないセットです。そうすれば、非 CODE_ANALYSIS 構成を構築するだけで、抑制したすべてのメッセージを確認できます。これは、抑制されたメッセージを定期的に確認し、必要に応じて対処または削除できることを意味します。

長期的にやりたいことは、実際のエラーに対して SuppressMessage 属性を分析し、不要になった抑制を強調表示するビルド ステップを用意することですが、それは現在、私のセットアップでは不可能です。

于 2008-09-28T18:13:56.027 に答える
1

私たちはウェブ ショップなので、次のルールを削除します。

  • 相互運用機能を備えたものすべて (クライアントが料金を支払わない限り、COM 統合はサポートされません!)
  • 鍵署名 (Web アプリには高度なセキュリティ権限は必要ありません)

一部の CMS はまだ .NET 2.0 であるため、依存関係で上位のフレームワークを使用することに関するルールを廃止することがありますが、それは、試していない限り、DAL/ビジネス レイヤーを .NET 3.5 にすることができないという意味ではありません。 IQueryable (または .NET 3、3.5) を返します。

于 2008-09-27T09:04:45.187 に答える
0

Sklivvzに完全に同意します。ただし、既存のプロジェクトの場合、FxCop 違反をカテゴリごとにクリーンアップできます。

時々、憲兵は非常に役立つ新しいルールを受け入れます。したがって、Gendarme を使用することもできます。

于 2008-09-27T10:05:19.360 に答える
0

設計とセキュリティのルールは、開始するのに適した場所です。

于 2008-09-27T08:34:24.917 に答える