コード内にバグ修正コメントを入れておくのは良いですか？

私のチームは、バージョン管理としてクリアケースを使用しています。私が取り組んでいるプロジェクトは、7〜8年前には開始されていません。プロジェクトの存続期間中、バグ修正サービスパックなどのリリースがいくつかありました。問題はバグ追跡システムを使用して追跡され、バグ修正に取り組むほとんどの人は、START /日付、作成者、バグIDなどを含むENDブロック

これは非常に無関係で、コードが乱雑になり、保守が不安になります。これらは、チェックインコメント/ラベルなどの一部である必要があり、作業製品の追加のライフサイクル情報を保持できます。

従うべきベストプラクティスは何ですか？

コードのレビューアの何人かは、バグと修正についてのコメントを外に出して、彼らの人生を楽にすることを主張します。私の理解では、ファイルをビューにマッピングしてファイルをレビューし、ブランチの変更ログを取得してレビューする必要があります。レビュー用に更新されたコードを送信する際のベストプラクティスを入手できれば助かります。

バグ修正をコメントとしてコードに追加することの問題は、完全なストーリーを取得できないことです。「これはバグの修正」というタグが付いた完全にすばらしいコードを見つけた場合、私の最初の反応は「そうですか？」と言うことです。コードはそこにあり、動作します。コードを維持するために知っておく必要がある唯一のことは、それが何をするかを教えてくれるコメントです。

より良い方法は、SCMコミットログにバグ修正参照を追加することです。これにより、バグの内容、導入された場所、および修正方法がわかります。さらに、リリースの時期が来たら、SCMログを簡単に抽出し、バグがあり修正されたことを示す箇条書きを追加できます。別のブランチまたはバージョンで同じバグが発生した場合、修正箇所を簡単に見つけて、それが実際に同じものである場合は簡単に再適用できます。

これをすべて言ったが、チャールズの答えにも同意する。コードの一部の理由が明らかでない場合は、必ずコードが理由があるため、注意して扱う必要があることをメンテナーに伝えてください。

主に悪い習慣。絶対にやるべきだとは言いません。時折、回避しなければならない外部APIのバグのようなものに遭遇します。根本的なバグを知らない場合、回避策は完全に脳死状態に見える可能性があります。その場合、同僚や後の自分が明らかに脳死したコードを「修正」しようとしないように、コードのバグを文書化することをお勧めします。

悪い練習。コメントは古くなり、コードが乱雑になります。情報は、必要に応じてSCCシステムのバージョン履歴で引き続き利用できます。

悪い習慣のようですね。組織が別のバグ追跡システムへの移行を決定した場合はどうなりますか？現在使用しているツールに製品を強く結び付けないでください。特定のバグIDを参照する代わりに、コードがそのように見える理由は不明であるため、コード内のコメントを使用して設計上の決定を動機付けます。

私の最初の反応は、自分自身を繰り返さないことですので、コードからそれをSCMログに入れてください。ここでは、関数の改訂コメント、作成者名、およびファイルと関数の作成日について、同様の議論を行いました。過去（SCMが使用される前）では、ファイルの進化を再構築できるように、この情報はすべてファイルに保存されていました。

開発者の約半数は、この情報がすべての情報を1か所に集められることを望んでいます（これにより、SCMの変更を検索するきっかけになります）。開発者の残りの半分は、coeで何が変わったかの手がかりを探すのではなく、コードの情報を必要としないようにSCMから検索を開始します。これらのコメントをどう処理するかはまだ決定していません。それは人々の働き方に大きく依存し、一部の人々は既知の方法を離れることに非常に頑固です。コードのブロックをコメントアウトし、コード内に永久に残すことについても同じです。

Dyaster らに追加するだけです。JIRAにはバグ修正に関連する変更を表示する優れた機能がありますが、バグ修正を文書化するのに最適な場所はテストケースです。どのバグが修正されたかを示すコメントなしでコードが明確でない場合、それは「コード臭」です。ただし、匂いをきれいにする時間がない場合、コメントはテストケースを参照する必要があります。テストケースでは、コードが実行していることをコードが実行している理由がより明確になります。バグ修正を説明するテストケースを作成する時間がない場合、バグはまだ修正されておらず、延期されています。

コード自体ではなく、コミットメッセージにバグ修正IDを追加することに同意します。バグIDのコミットメッセージを自動的にスクレイプするバグトラッカーは非常に便利です。

さらに、非難 / annotate /を使用できますバージョン管理システム praiseコマンドをして、これらのコメントを置き換えることができます。次に、次のようなものを実行すると：

vcs blame file.ext

通常、各行を誰が変更したか、いつ変更したか、コミットIDなどの有用な情報を確認できます。コミットIDから、バグIDを含むメッセージ全体を取得できます。

優れたVCSシステムを使用すると、誰が行を変更したかを計算するときに空白を無視できます。

この機能に関してClear Caseが何を持っているのかわかりません。