web-dev-qa-db-ja.com

"// ..."}の後のコードブロックの最後のコメント-良いですか悪いですか？

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

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

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

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

そして時には

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

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

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

source-codecomments
18
gablin

コードが長すぎて中括弧を簡単にたどることができない場合、ほとんどの言語では、コードにリファクタリングが必要です。

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

32
Matt Ellen

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

18
Alb

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

  • 最新のIDEのほとんどは、キャレットがいずれかの記号上にあるときに対応する中括弧を強調表示します。
  • きれいにコーディングしている場合、メソッドが10行を超える場所はめったに見つかりません。

私は多くのJavaプログラマーがこの考え方を持っていることに気づきます、そしてそれはJavaコードが本当に汚く見え、コードからフォーカスをコメントに向けます。

非常にこれを使用しないことをお勧めします。

15
Sergio

コードは、書き込まれた回数の10倍以上読み取られます。

それが読みやすくなる場合は、それを行ってください。

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

しかし、時々人々は学んでいます。これが彼らがやっていることであるならば、それは本当にコードをより読みやすくすることであり、それを奨励し、そして他のいくつかの実践も奨励します。学習している人は、どのように始めても関係なく、励ましの恩恵を受けるに値します。 「これは悪い」と言っても、「これ以外のほうがいい」と言うほど役に立ちません。

6
Lunivore

C++には2つのホールドオーバーがあり、これは依然として有用であり、「コードを分割する」というアドバイスはホールドする必要はありません。

  1. 名前空間の場合。名前空間にはファイル全体を含めることができ、最後の角かっこで人が見落とされる場合があるため、角かっこで名前空間を閉じることを示すコメントを追加すると便利です。私の会社の特定のコーディングスタイルでは、名前空間をインデントしないため、これは重要です。なぜなら、そのようなインデントはファイル内のスペースを浪費するだけであると判断されたからです。

  2. #ifdef/#endifペアの場合。時々、条件付きコンパイルのためのコードがたくさんあり、ネスティングで厄介になる可能性があり、私たちが頻繁に「手助け」して頻繁に使用するエディターはインデントを排除するため、コメントは簡単な概要の中で役立ちます。

4
Joris Timmermans

私はこの種のものでいっぱいの大きな（C++）コードベースを持っています：

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

これほど小さいものについては、これは「コードのにおい」を超えて「コードの悪臭」になると思います。特にIDEでは、右中かっこをキーストロークと照合して、左中かっこを見つけることができます。より長い方法が与えられた場合でも、最後のコメントに対して中かっこを一致させることになります。このようなコメントは注意をそらします私と私はそれらをノイズとして考える傾向があります。

4
PSU

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

// IFステートメントとだけ書かれている場合。そもそもなぜそこにあるのか不思議に思わざるを得ません。

1
TeaDrinkingGeek

ブレースが閉じているものを確認する代わりに、最初のブレースを最後のブレースと同じ列に配置することもできます。その方がはるかに明確で読みやすくなっています。

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

1
CashCow

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

とは言っても、ベーコンを何度か救ったとしても、大会に暖まることはありませんでした。ただのノイズだと思っています。ループや条件文がそれほど大きくなっている場合は、ええ、リファクタリングを検討する必要があるかもしれません。

1
John Bode

基本的に、これを使用しない理由をすべて有効にしてください。すべてのまともなプログラマはこれらを適用する必要があります。では、なぜdo人々はそれを使うのでしょうか？彼らはそれを間違ってやっていて、よく分からないからです。

0
stijn