長いコメントが必要な場合もあります。これは、長い説明が必要な厄介なハックがある場合に発生する可能性があります。はい、ハッキングを完全に回避/修正することをお勧めしますが、多くの場合、時間的なプレッシャーがあり、将来に先送りする必要があります. その場合、ハックをより良いコードに置き換えようとしている人を含め、詳細なコメントがあると非常に役立ちます。重要なのは、ハッキングが何をしているのか、そしてその理由を正確に理解することです。
多くの場合、複数の段落が必要です。のような空白のコメント//が許可されている場合、コメントはより読みやすくなります。ただし、StyleCopそれらは気に入らず、全体的に同意しているため、すべての提案に固執するようにしています. 今、私は3つのオプションを考えることができます：
//// This is a hack ...
//// ..................
////
//// When fixing this hack make sure ...
//// ...................................
(私は通常、コードのセクションをコメントアウトするために二重/三重/四重のコメントを使用するため、最初のコメントは好きではありません)。
// This is a hack ...
// ..................
//// <== This will slide, but I think it looks dumb.
// When fixing this hack make sure ...
// ...................................
(私は 2 番目のオプションが好きではありません。ちょっとばかげていると思います)
// <para>
// This is a hack ...
// ..................
// </para>
// <para>
// When fixing this hack make sure ...
// ...................................
// </para>
(私は 3 番目のオプションも好きではありません。メソッドのドキュメントには適して///いますが、ここでは場違いに見えます。
より良い方法を提案してください。