10

MSDN属性チュートリアルでは、Author属性の例として次のように使用しています。

[Author("Jane Programmer", Version = 2), IsTested()]
class Order
{
    // add stuff here ...
}

これは、作成者ごとにクラスをグループ化するためのリフレクションを使用できるため、私には良い考えのように思えました（たとえば）-通常はドキュメントにあるメタデータをコンパイラに効果的に公開します。これは便利です。私はすぐに「ああ！すべてのインラインブロックドキュメントに属性を使用する必要がある」と思いました-例：

[Author("Me")]
[Description("Add 1 to value")]
[Param("value", "The original value to add 1 to")]
public int AddOne(value) {return value + 1;}

ただし、ドキュメントと属性について私が見つけた答えはどれも、この方法を示唆しているようには見えません。 それらはすべて、インラインドキュメントにXMLを使用します。

インラインドキュメントを支援するための組み込み属性はありますか？そうでない場合、インラインドキュメント用の事前定義された属性のセットを含むライブラリ/パッケージはありますか？

4

3 に答える 3

5

ドキュメントを属性に保持することのいくつかの欠点：

  • 長いテキストのフォーマットが不十分。
  • Visual Studioアドオンによるサポートなし（たとえば、ReSharperのドキュメントプレビュー機能の使用）。
  • サードパーティのドキュメント生成ツールによるサポートはありません。
  • リバースエンジニアリングを大幅に容易にするドキュメントをアセンブリに含める。
  • ソースコード内のメタデータとバージョン管理システムに保存されているメタデータの複製（VCSがはるかに正確な情報を提供する場合、ソースコード内の宣言の作成者とバージョンを追跡する意味はありません—VCSは嘘をつきません）。

今のところアドバンテージは考えられません。本当に必要な場合は、XMLドキュメントのコメントを解析して、コードベース全体を任意の属性形式に変換することが常に可能です。

于 2012-10-01T10:02:47.853 に答える
3

ここでの質問は、「ドキュメントとは何ですか？」のようです。関心のある「もの」にリフレクションによってアクセスできる必要がある場合は、属性の暗黙のソリューションがソリューションです。ただし、標準のドキュメントツールを使用してドキュメントを作成することが目的の場合は、そうではありません。

ここでの必要性は解決策を求めます。「文書化」の必要性は何ですか。おそらく間違った質問ですか？

于 2012-10-01T10:10:37.760 に答える
0

完全を期すために言及するだけで、テストプロジェクトでは次のことができます。

[TestProperty(“Author”, “Ducky”)] 
public void SomeTest()
{
       ...
}

そのアプローチを通常のコードに拡張することができます。理論的な問題についてはコメントしません。そうは言っても、リポジトリを使用して特定のファイル/クラス/メソッドのすべての「作成者」/「編集者」を抽出するスクリプトを作成できる可能性があります。

于 2012-10-12T12:27:27.110 に答える