}の後のコードブロックの最後にある「//…」コメント-良いか悪いか [閉まっている]

私はしばしばそのようなコメントが使用されるのを見ました：

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

そして時には

if (condition) {
   ...
} // if (condition)

私はこのプラクティスを理解したことがないため、適用しませんでした。コードが非常に長いため、このエンディング}が何であるかを知る必要がある場合は、おそらくコードを個別の機能に分割することを検討する必要があります。また、ほとんどの開発者ツールは、一致するブラケットにジャンプできます。最後に、最後の点は、私にとって、DRY原則への明らかな違反です。条件を変更する場合は、コメントも変更することを忘れないでください（そうしないと、メンテナーやあなたにとっても面倒になります）。

なぜ人々はこれを使用するのですか？それを使うべきですか、それとも悪い習慣ですか？

コードが長すぎてブレースを簡単に追跡できない場合は、ほとんどの言語でコードをリファクタリングする必要があります。

ただし、テンプレート言語（PHPなど）では、条件またはループ構造の開始と終了を分離するHTMLの大きなブロックがあるため、有効な場合があります。

それはコード臭であり、通常、昔ながらのコードスタイルからの二日酔いです。まともなIDEのリファクタリングは以前より難しく、現在ほど一般的ではなかったため、メソッドが長くなり、これらのコメントはそれらをよりうまくナビゲートするのに役立ちました。

これは多くの要因によって時代遅れになった恐ろしい習慣です。

• 最新のIDEでは、キャレットがいずれかのシンボル上にある場合、対応するブレースが強調表示されます。
• きれいにコーディングしている場合、メソッドが10行を超える場所を見つけることはほとんどありません。

多くのJavaプログラマーがこの考え方を持っていることに気付きます。これにより、Javaコードは本当に汚く見え、コードからコメントに焦点が移ります。

これを使用することを強くお勧めします。

コードは、記述されているよりも10倍以上読み取られます。

読みやすくする場合は、実行してください。

また、これを行う人には、読みやすくするために他の方法を検討することをお勧めします。他の人が言及したリファクタリング手法、異なる行の括弧などはすべて良いです。コードを自己コメントにするために、さまざまな関数、メソッド、またはクラスに物事を分割することも良い方法です。また、ほとんどの「if」を削除し、「for」ループを明白な場所に配置する方法もあります。そのため、これらのいずれの必要もありません。

しかし、時々人々は学んでいます。これが彼らがしていることであるならば、それはコードを本当に読みやすくすることであり、それを奨励し、そして次にいくつかの他の慣行も奨励します。学んでいる人は、彼らがどのように始まったかに関係なく、励ましから恩恵を受けるでしょう。「これは悪い」と言うことは、「この他のことは良い」と言うほど有用ではありません。

この種のことでいっぱいの大きな（C ++）コードベースがあります。

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

これほど小さいものについては、これは「コードのにおい」を超えて「コードの悪臭」につながると思います。特に、閉じ括弧をキーストロークと一致させて開き括弧を見つけることができるIDEで。より長い方法が与えられたとしても、私はまだ端末コメントを介して中括弧を使用します。そのようなコメントは私を混乱させ、私はそれらをノイズと考える傾向があります。

C ++には、これがまだ有用であり、「コードを分割する」というアドバイスが不要な2つのホールドオーバーがあります。

1. 名前空間用。名前空間はファイル全体を含むことができ、その最後のブラケットは時々人を捨てることがあります。そのため、ブラケットが名前空間を閉じていることを示すコメントを追加すると便利です。私の会社の特定のコーディングスタイルでは、名前空間をインデントしないため、このようなインデントはファイル内のスペースを無駄にするだけなので、これは重要です。

2. #ifdef / #endifペアの場合。条件付きコンパイル用のコードがたくさんある場合があり、ネストすると厄介になることがあります。私たちが頻繁に使用するエディターは、インデントを「役立つ」方法で削除するので、コメントは簡単な概要で役立ちます。

私にとって、コードはあなたが指定したようなコメントを追加するのを混乱させなければなりません。

// IFステートメントと表示されている場合。それから、そもそもなぜそこにあるのか疑問に思うようになりました。

ブレースが閉じていることを確認する代わりに、開いているブレースを閉じているブレースと同じ列に配置します。私はそれがはるかに明確で読みやすいと思う。

コメントは、オープンがかなり前に行われたためにトレースするのが通常困難な場合に役立ちます。これは通常、名前空間（特に、コンパイル単位で実装の詳細に使用されるC ++の匿名の名前空間）に対してのみ発生します。他のほとんどの場合、何を閉じているのかが明らかです。

これは、特にEVEのようなウィンドウエディタを使用している場合、80x24文字のターミナルウィンドウで作業していた昔からの大部分のホールドオーバーです。今でも、vimを使用してターミナルセッションでほとんどの作業を行っています。セッションを3つまたは4つのサブウィンドウに分割できるため、一度に実際に表示できるのは数行だけです。

そうは言っても、何度もベーコンを節約できたとしても、コンベンションに本当に温まることはありませんでした。私はそれをノイズと見ています。ループや条件が大きくなっている場合は、そう、リファクタリングを検討したいかもしれません。

基本的に、これを使用しない正当な理由をすべて示します。すべての適切なプログラマはこれらを適用する必要があります。なぜないの人々はそれを使うのか？彼らはそれを間違っているので、よく知らないからです。