私の前の質問に関連しています。インターフェイスを定義する場合は、そのメンバーにコメントします。次に、元のコメントが無効になる理由がない限り、実装クラスの実装にコメントを付けません。
Resharperはこれで問題ありません、Visualstudioはそれが警告であると主張します。
重要なのは、継承されたコメントは、それらを操作するときにインテリセンスを介して表示されることです。これは、私の唯一の本当の関心事です。
これについてどう思いますか?
ありがとう
私の前の質問に関連しています。インターフェイスを定義する場合は、そのメンバーにコメントします。次に、元のコメントが無効になる理由がない限り、実装クラスの実装にコメントを付けません。
Resharperはこれで問題ありません、Visualstudioはそれが警告であると主張します。
重要なのは、継承されたコメントは、それらを操作するときにインテリセンスを介して表示されることです。これは、私の唯一の本当の関心事です。
これについてどう思いますか?
ありがとう
コードにコメントを追加することは、常に良い習慣です。コンポーネントがプライベートクラスまたは内部クラスであり、すべてのコメントが配置されている既知のインターフェイスまたは抽象クラスを介して常に公開される場合は、そのクラスの実装に関する特定の事項にのみコメントする必要があります(たとえば、 1人以上がコードを見る場合、または数年後にコードに戻った場合)。そうすれば、コードの機能とその理由を理解しやすくなります。プロジェクトのビルド時にXMLドキュメントの生成を有効にしている場合、VisualStudioはドキュメント化されていないメンバーについて警告します。
XMLドキュメントの生成を有効にすると、一部のクラスでResharperの警告も表示されますが、Resharperは一般公開されているアイテムに対してのみ警告を表示します。ドキュメントの作業を短縮するために、最初にパブリッククラスとインターフェイスにコメントすることをお勧めします(特に製品ライブラリをリリースする場合)。十分な時間があれば、内部/プライベートのものにコメントします。後者にコメントしないことにした場合は、コードを操作する人がロジックとその背後にある理由を簡単に理解できるようにしてください。
同じ「問題」が発生しましたが、VisualStudioがコードの臭いを適切に報告していると思います。
私が正しく理解しているなら、あなたの問題は、あなたのインターフェースとあなたの実装について同じコメントに相当するものを持っているのは乾いていないということです。これは非常に理にかなっています。多くの場合、特にモックやテストを行う場合、コードは実装ではなくインターフェイスを使用します。なぜ複製するのですか?
さて、あなたのクラスはマークされているに違いないpublic
。その場合、外部コードによってインターフェイスなしでクラスを使用できます。これらの外部ユーザーはコメントに値するものであり、実装しているインターフェースのリストに含まれていない追加のパブリックメソッドがいつあるかはわかりません。コメントしてください!
ただし、これらのコメントを作成したくない場合は(少なくとも、VS 2017では、2013を使用していたと思いますが、これは便利ではありません)、実装クラスにマークを付けinternal
てコメントをスキップできます。
そして、unDRYコメントの問題が解決されます。