問題タブ [stylecop]

重複の可能性:
Usings は名前空間の内側または外側にある必要があります

sa1200 すべての using ディレクティブは名前空間 (StyleCop) 内に配置する必要があります

これはコードの読みやすさのためだけですか、それともそうすることに実際の利点はありますか? どういうわけかGCに役立ちますか？

コードの一部に対してスタイル警官を実行していたところ、いくつか得られました。

誤解しないでほしいのですが、私はスタイル コップが好きです。複数の人と一緒にプロジェクトに取り組むときは素晴らしいのですが、このルールは私には少し過剰に思えます。追加する理由:

すべての変数の先頭に。誰かが (Martin Fowler, Kent Beck.. ATM はよく覚えていない) コメントは「何」ではなく「なぜ」と言うべきだと言ったことを覚えていると確信しています。変数。

また、すべての変数にコメントがあるコードは読みにくいと思います。

私の考えでは、すべての変数が何であるかを説明する必要がある場合、名前付けに関しては本当に失敗しています。

他の誰かがコメント変数にコードの匂いを感じているのですか、それとも私だけですか?

sylecopを発見し、プロジェクトで実行しています。名前空間内での使用など、特定のルールを無効にしました。ただし、たとえばボタンクリック用のVisual Studioの自動生成イベントハンドラーは、btnOk_Click（...。

これは、他の方法と同様に大文字で始まる必要があるため、stylecopのデフォルト設定に準拠していないことを理解しています。しかし、コード例などでは、常に標準のように見えます。私はイベントハンドラーのこの形式にも慣れているので、この検証からイベントハンドラーを除外するが、他のメソッドは検証されたままにする方法はありますか？

私はStyleCopを実行しています（高品質のコードを提供したい場合は、これを完全にお勧めします）...

私はこの行を持っています

更新もこれを試しました

StyleCop がエラーを報告しています

これが無効である場合、何が有効ですか?

次のような方法で、CI ビルド プロセスに StyleCop を統合するように依頼されました。

• (大規模な) ソリューションの個々のプロジェクト ファイルは影響を受けません
• サードパーティのツールを使用する必要はありません

最初の要件 (まだ完全には理解していません) は、ソリューション全体で StyleCop を直接実行したくないという事実によるものです。どうやら、VS 内から StyleCop を実行すると、無視するファイルを指定する特定の属性が無視されます。このため、開発マシンで実行すると、まだ対処する準備ができていない何千もの違反に継続的に遭遇します。要するに、ビルド サーバーでのみ実行できるようにしたいということです。

私たちのビルド環境は現在、次のもので構成されています。

クルーズ コントロール > msbuild を実行する nant タスク (exec 経由)

nant タスクは以下のとおりです。

これを最初に見たとき、msbuild が実行されているのと同様の方法で StyleCop を実行する単純なケースだと思いました。

ただし、StyleCop は dll のセットとして提供されます...

ということは、自分の意図したことができていないということ……だと思います……。

今日私がグーグルで検索したすべての記事は、「StyleCopCmd を使用する」と述べていますが、これもサードパーティのツールの制限のために実行できません。

このツールを調べたところ、StyleCopConsole を開始し、いくつかのイベントにフックして適切にフォーマットされたレポートを出力するカスタム nant タスクが実装されているようです。しかし、社内でツールを作成することを正当化できるようにするためには、nant 構成ファイルで目的を達成できない理由を完全に説明できる必要があります。または、ツールの作成または使用を伴わないその他の方法で。そして理想的には、とにかくツールを作成したり使用したりする必要がなければ、より高速になります。

だから私の質問は、それは可能ですか？

これは、特定の StyleCop 構成の問題です。

Visual Studio .Net ソリューション フォルダーに合計 2 つの Settings.StyleCop ファイルがあります。

1 つ目は、チーム用に選択されたルールとともにフォルダ ルートに配置されます。

特定のプロジェクトのいくつかのルールを無効にしたいので、対応するプロジェクト フォルダーに別の Settings.StyleCop ファイルを配置しました。

結果は次のとおりです。

• Visual Studio IDE (Run StyleCop) から分析を起動すると、プロジェクト固有のファイルが考慮され、違反は発生しません。
• StyleCopCmd (コマンド ツール) から解析を起動すると、プロジェクト固有のファイルが無視され、違反が発生するようです。
• MSBuild ターゲットから解析を起動すると、プロジェクト固有のファイルも無視されるようで、違反が発生します。

とは異なる結果になるように StyleCop 構成で何かを見逃しましたか?

使用しています: Windows XP StyleCop 4.3 MSBuild 3.5 SP1 MSBuild 拡張パック 3.5.0.0 StyleCopCmd 0.2.1.0

問題は StyleCop 4.3.1.3 および MSBuild Extension Pack 3.5.3.0 でも同じようです。

よろしく、

オリビエ。

カスタム環境で StyleCop をホストしたいのですが、SDK で提供されているサンプル コードはこれを使用していforeach(string myProject in this.myProjects)ます。にはやのStringようなプロパティはありません。Path.GetHashCode()FilesToAnalyzethis.myProjects

コードを改善するために StyleCop と FxCop ツールを使用していますが、StyleCop と FxCop の 2 つのルールが存在する場所に行き着きました。StyleCop のルールに一致するようにコードを修正すると、FxCop の検証が失敗し、その逆も同様です。

最初のルールは StyleCop の SA1200 で、すべての using ディレクティブは名前空間内に配置する必要があると述べています。

すべての using ディレクティブは、名前空間内に配置する必要があります。

だから私はこのようなことをしました

StyleCop では問題ありませんでした。警告はなくなりました。ここで FxCop 検証を実行すると、CA1014 に違反していることがわかります。

'MyApp.dll' を CLSCompliant(true) でマークします。これは、外部から見える型を公開するためです。

これを解決するには、次のようにする必要があります。

ClsCompliantしかし、属性が認識されないため、プロジェクトをビルドできません( のSystem中に含まれる名前空間からのものであるためMyNamespace)。したがって、using System; ディレクティブをMyNamespace宣言の外に移動すると。これにより、コードがコンパイルされますが、StyleCop のルールが破られます。

StyleCop または FxCop のルールの 1 つを無効にする以外に、この問題に対処する方法はありますか? それが不可能な場合、どのルールを無効にする必要がありますか? 重要度が低いのはどれですか?

これを行う方法は知っていますが、StyleCop メソッドが真であるかどうかはわかりません。通常、StyleCop ルールでは、この例のようなものをヘッダーに追加する必要があります (編集する必要があります)。

そして、ReSharper の StyleCop を使用すると、次のようになります。

私の最終的なヘッダーは次のとおりです。

このヘッダーをすべてのソースと共有に追加すると、アプリケーションは GPL ライセンスになりますか? そうでない場合、どこに問題がありますか? StyleCop メソッドが機能することを願っています。おそらく、「{プログラムの名前とその機能の簡単なアイデアを示す 1 行}」を著作権タグよりも上に移動する必要があります。ありがとう。

私は常に、依存関係プロパティ (登録、clr プロパティ、変更コールバック、強制コールバックなど) に属するすべてのものを 1 つの領域にグループ化する傾向があります。しかし、これは stylecop メンバーの順序規則に違反しています。スニペットはファイル内の異なる場所でコードを生成できないため、これは複数のメンバーを生成するコードニペットの一般的な問題でもあります。これについてのあなたの哲学は何ですか？stylecop ルールを無効にしますか、それともすべてを「適切な」場所に配置しますか?

また、個人的には、stylcop はこれについて不平を言うべきではないと思います。

Stylcop は、私たちが行う追加の作業を生成する必要があります。上記の例では、stylcecop に固執すると生産性が低下し、コードが読みにくくなります。これは、FrameworkPropertyMetadata を一時変数にできるようにするために、(フィールドの初期化ではなく) 静的 ctor に上記のコードを配置する必要があるためです。依存関係プロパティごとに一時変数を 1 つ追加しても、コードが読みやすく、保守しやすくなるわけではありません。また、コードニペットを使用できなくなります。