web-dev-qa-db-ja.com

有益なコメントとコメント化されたコードを区別する方法はありますか？

プログラミングの過程を通して、コードを説明するコメントと、コードを削除するコメントができあがります。

// A concise description 
const a = Boolean(obj);
//b = false;

どれがどれであるかをすばやく解析するための良い方法はありますか？

私は3を使って遊んだ/'砂 /** */は説明コメントです。

VSCodeプラグインを使用して//TODO:および//FIXME:

javascriptcomments
38
Ace

これには非常に簡単な解決策があります：コメント化されたコードを削除します。

実際、コードをコメントアウトする理由は2つだけあります。何かをテストするか、修正を行うか、後で使用するコードを保存するかです。何かをテストまたは修正している場合は、テストまたは修正が完了したらすぐに、コメント化されたコードを削除してください。後で使用する可能性があるコードを保存する場合は、それをファーストクラスのコードにして、ライブラリなどの適切な場所に配置してください。

190
Robert Harvey

追加 @ RobertHarveyの優れた答え コメント付きコードをソース管理に一時的にでも保存するために私が遭遇した正当な理由は1つだけだと思います：nonの場合-何らかの理由で現在使用できない、または使用できない明白な置換コードそれでも、コメントのほとんどはの説明である必要があります置換コード。これは、バグまたは言語の機能であり、まだ安定しているとは見なされていません。次のようになります。

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

この場合、作業はすでに完了していますが、まだ活用できていないため、削除すると、後で再発見する必要があります。同じことが 一見すると優れているように見える次善のソリューション または 同様のソリューションに対する意識的なトレードオフ にも当てはまります。

注意：別のソリューションでコードを散らかさないでください。すべてのタスクはさまざまな方法で無限に実行でき、すべての変更に対してこのスペースを長時間探索するのは費用対効果が高くありません。コードレビューは、同僚がすでに最適ではないことがわかっている改善点を提案したときに、そのような欠けているコメントを発見するのに適した場所です。

45
l0b0

うーん、私はこの質問を、コメントアウトされたコードを削除する必要があると正しく主張するRobertとは少し異なります。

ただし、後で削除するためにコードにマークを付ける規則を探している場合、私のお気に入りは次のとおりです。

//b = false; //TODO: remove

一部のIDEのフラグ//TODO:コメントまたは教えられることができます。そうでない場合、通常は検索可能な文字列です。これはいくつかの方法で行うことができるので、あなたの店が確立したどんな慣習にも従うのが最善です。すべてのコードベースがこれを1つの方法で行う必要があります。検索可能に保ちます。

どっちがどっち？

そのマークがない場合、これを行う自動化された方法はコンパイラを使用することです。コメントを削除してコンパイルするコードが生成される場合は、コメント化されたコードである必要があります。難しいことではないことを確認するIDEプラグインを作成します。ただし、バグのあるコメント付きのコードが残ります。

これが、コメントアウトしたコードをコメントアウトした瞬間にコードとしてマークする方が良い理由です。これにより、本当に破壊したいかどうかを決定しながら、非破壊的に作業できます。私たちは皆、中断されていくらか忘れているので、その状態のときにいくつかの行がチェックインされても驚かないでください。彼らがそうするなら、彼らが少なくとも明確にマークされて検索可能であるのは素晴らしいことです。キーボードマクロはこれまで私に役立ちました。単一のキーストロークでこれを行うことができる場合、この途中で中断されることは困難です。

これは、継続的インテグレーションテストでマークを使用する限り可能です。エラーが発生しました。未処理のTODOでチェックインしようとしています。

20
candied_orange

私はプリプロセッサディレクティブを使用して、コメントではなくコードを削除します。

_//comment
active_code();
#if FALSE
inactive_code();
#endif
_

これは非常に簡単に検索できるものになり、私の構文ハイライターはそれをコメントとして扱います。それを1行に折りたたむこともできます：#if FALSE(...)

そのアイデアを拡張して、いくつかのオプションを設定できます。

_#if OPTION == 0
code_for_option_0();
#Elif OPTION == 1
code_for_option_1();
#else
code_for_all_other_options();
#endif
_

そしてコンパイル時のエラーチェック：

_#if FOO >= 5
#error FOO should be less than 5!
#endif
_

もちろん、これをやりたくないと、実際にコンパイルされているものとコンパイルされていないものを区別するのが難しくなります。しかし、あなたはアイデアを得ます、そしてそれはとにかくコメントされたコードと同じ問題です...それを静的に使用するだけである限り。あなたの状態が動的であるならば、それはさらに悪いです。

この問題をまったく考慮していなかった既存のコードベースのどれがどれであるかを判断するために、普遍的な解決策はないと思います。自分でパターンを見つけ、おそらくそれらを見つけるために正規表現をコーディングする必要があります。

8
AaronD

古いコードは可能な限りコメントアウトするのではなく削除する必要があるという回答に同意しますが、コメントアウトされたコードが必要な場合の慣例を確認しました。

（私の基礎はC＃ですが、これはJavaなどの任意のC構文言語に適用できます）

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) {
//   doSomethingElse();
//}
4
IanF1

コメントアウトされたコードを見つけたいと思って、私はまだ別の質問を解釈しています。

Cスタイルのコードはセミコロンを含むようにバインドされていますが、コメントはセミコロンを含む可能性が低いです。したがって、1行コメントアウトされたコードの場合、次の正規表現を使用できます。

\s*\/\/[\s\S]*;

複数行コメントアウトされたコードの場合、

\/\*[^\;]*;[^\;]*\*\/

注Visual Studioは正規表現の改行に少し特有であり、空白としてはカウントされません。明示的に\ nを指定する必要があります。

2
Martin Maat

コンパイラをバックグラウンドで実行しているエディタ（XcodeやClangなど）を使用している場合は、コメントのテキストをコンパイルしてみてください。たとえば、「簡潔な説明」は「b = false;」というエラーを出します。しません。次に、異なる構文の強調表示を使用できます。

より簡単な方法は、IDEプラグインで、キーワードがコメントを指す、行が中括弧で囲まれたコードがコードを指すなど、行内の複数の単語が一致するようなヒューリスティックを使用します。

2
gnasher729

他の回答では、「コードをコメント化しない」というテーマのバリエーションについて説明しています。しかし、時にはそれを参考にしたいことがあります。

コードをそのままにしておく必要がある場合は、コードを「#if 0 ... #endif」で囲むのが理想的です。理想的には、理由を説明するコメントを付けることです。これは、MISRAを含むさまざまなコーディング標準からの推奨戦略です。

1
Graham