version-control - コメントの古いコード

Question

コードベースで古いコードをコメントアウトした期間はどれくらいですか? 請負業者は、古いコードをコメントに変換することにより、コードベースに保持し続けます。これは本当にイライラするので、古いコードをコメントアウトするのではなく、単に削除してほしいと思っています。

コードベースに古いコードをコメントとして残す正当な理由はありますか? Visual Sourcesafe によるバージョン管理を使用しています

score 50 · Accepted Answer

SVN や CVS などを使用している場合は、いいえ。私はそれらを一目で消去します。コードが読みにくくなります。

コメントは、コードを読んだり、説明したりしているプログラマーを助けるためにそこにあるべきです。

score 14 · Accepted Answer

私が考えることができる正当な理由は、この（架空の）例です：

# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a

基本的には、何らかの理由で削除されたコードを他の開発者が再挿入できないようにするためです。

score 10 · Accepted Answer

請負業者にこれをやめるように伝えてください。これはひどい習慣です。

古いコードをコードベースに残す理由はまったくありません。邪魔になるだけです。バージョン管理システムは、各ファイルの履歴を表示します。

古いコードを保持する唯一の正当な理由は、おそらく歴史的な参照のためです (おそらく、古いコードが現在の状況に関連する可能性のある特に奇妙なことをした場合)。

時折、一時的な変更 (一時的な変更とは数日以内という意味) を入れていることを知ってコードをコメントアウトし、間違いなくそれに戻る予定です。

編集：別の関連する慣行は、ファイルに変更の名前と日付を入れることです：

// 06/20/2009 - joe changed this #1245

これもしないでください。誰が変更を行ったかを確認することは、その時点では価値があるように思えるかもしれませんが、時間の経過とともに、実際には何の価値もなく、コードが乱雑になります。

score 4 · Accepted Answer

あなたは「どのくらい？」と尋ねます。人々がまだ作業しているホットスポットである場合、1 つまたは 2 つの場所に古いコードが含まれていても、気分を害することはありません。

おそらく、彼らはまだ新しいコードに自信を持っていないのでしょう。新しいコードは「完了」していますか? あるべきように書かれていますか？テストに合格しますか？それはコメントされ、仕様に文書化されていますか? パフォーマンスはあるべき場所にありますか? (古いコードと新しいコードの両方を使用する最も良い理由は、特定のケースセットのタイミングを計ったり、プロファイリングしたりする場合です。)

古いコードについて、新しいコードよりも優れている点はありますか?

請負業者は急いでいますか？それとも、バージョン管理前の古い習慣ですか?

score 4 · Accepted Answer

あるべきソース管理を使用している場合は、古いコードを削除してください。コピーはソース管理の準備ができており、元に戻す必要がある場合に備えて待機しています。そこに古いコードがあると、上記のようにコードを読み取る能力が低下し、混乱が生じます。また、請負業者を使ってコードを書いている場合は、賃金を払っているので、コーディング方法を教えてください。それらのコーディング標準を定義し、メソッド、プロパティなどの名前を改善し、コメントの必要性をまとめて減らすために意図的にコード化します。

score 3 · Accepted Answer

Sourcesafe は履歴を保持するので、請負業者はコードをコメントアウトする必要はありません。

何らかの理由で信頼されていない可能性があります。彼らからその理由を聞き出すことができれば、彼らは注意を払うかもしれません。何年も前に VSS から移行したのは、信頼性とスケーラビリティの問題が原因であったことも知っています。VSS がニーズに適していることを示すか、他のソース管理ソリューションを調査することを示すことによって (もちろん予算がある場合)、彼らの懸念に対処できる場合は、彼らを説得する必要があります。

説得は強制よりも優れています。

score 2 · Accepted Answer

ええ、見えたらそれを核攻撃してください。コメントした開発者が削除について確信が持てなかったことを示す以外に、何の価値もありません。または、ソース管理ソフトウェアの使い方を知りません。

score 2 · Accepted Answer

基本的に、2 つのオプションしかありません。

それを削除します-それは、コードリポジトリを使用する場合です。リポジトリはどのような変更が行われたかを正確に教えてくれるので、簡単な言葉で何かを説明していない作業コードに長い古いコメントを残す必要はありません。
一方、いくつかの理由でそのコードを保持したい場合、たとえば、アプリケーションの浮動小数点計算コードをコメントアウトして保持しました。これは、プログラミングしていたプラットフォームで機能しなかったためです。しかし、アプリケーションをそのプラットフォームに限定したままにしたくないので、コードをそこに残したので、浮動小数点計算をサポートするプラットフォームにアプリケーションを移植するときの労力を節約できます。これは、古いコードを保持する理由の 1 つにすぎず、同じバックグラウンドを持つ人々にも当てはまる可能性があります。

それ以外の場合は、上記の 2 つの選択肢しかありません。あなたの電話!!

score 1 · Accepted Answer

古いコードを残しておくと、コード全体を読むのが難しくなります。プロジェクトに何らかのバージョン管理が行われている限り、コメントアウトされたコードは削除する必要があります。リビジョン管理がなく、設定もできない場合は、コードベースの一部ではないファイルに古いコードを配置することをお勧めします。

score 1 · Accepted Answer

ここかそこらの奇妙な行だけでなく、何らかの価値があると思われる重要なコードブロック、またはそれ自体が優れたアルゴリズムを参照していると思います。

このような場合、コメントがコードレビューの形式として機能するため、大きな変更を加えた場合は、古いコードを保持するという自然な傾向があります。最新バージョンを入手した人は誰でも、行われた大きな変更を即座に見ることができ、問題があった場合、以前そこにあったものをはるかに簡単に確認できます. 問題が新しいコードにある場合は、すぐに確認できる非常に簡単な方法があります。

そのため、私は最初のリビジョンで古いコードをコメントアウトし、その後コードが再度変更されたときにのみ削除する傾向があります。この時点までに、変更は「定着」しており、バグ。

これらのコメントはドキュメントの形式であり、「クリーンな」コーディングの純粋な理想のためにそれらを削除する必要はありません。不要になったら削除し、価値がある間は保管してください。

score 0 · Accepted Answer

まず、それを取り除くと言います。

しかし、そうしない理由が 1 つあります。それは、バージョン管理に残っているからといって、だれもがそれを見ることができるわけではないということです。もう一度見る必要がある場合は、まずそれがかつて存在していたことを知る必要があります。将来の開発者が古い方法と新しい方法の両方を確認する必要がある変更を行う場合があります。古い方法を削除した場合、開発者はそれがかつてそこにあったことをどうやって知るのでしょうか? ほとんどの人は、この種の問題に対してバージョン管理の変更を十分に文書化していません。

score -1 · Accepted Answer

古いコードをそこに残す理由はたくさんあります。基本的に - 削除されると、誰かが実際にそこにあったことを覚えていない限り、事実上消えてしまいます。

悪意のある請負業者として、手順を大幅に書き直さない限り、コードを削除しません。つまり、「修正」するのではなく、破棄して置き換えることです。

score -1 · Accepted Answer

私が現在紹介しているプロジェクトは、さらに別のアプローチを使用しています - ある種の妥協...コードの一部が使用されなくなったと判断したら、単にそれをコメントアウトし、コメントアウトの日付を書きます。 (可能であれば - たとえば Netbeans や VisualStudio で) 古いコードを #region OLD_IMPL に挿入します。効果？- 念のため、まだ古いコードを持っています - 未使用のコードのブロックはちょうど 1 行です (#region OLD_IMPL) - そのコードが 1 年間使用されていない場合 (コメントアウトした日付があります)、単純に消して。

重大な状況が発生した場合は、常に SVN を使用してください ;)

score -2 · Accepted Answer

バージョン管理ツールが遭遇する可能性のある問題を解決するので、コメントアウトされたコードを取り除くと言う人はばかです。

廃止されたコードが本当に廃止されていることを確信したら、廃止する必要があります。

「完全に悪いわけではないが、残念ながら完全に良いわけでもなかった」という理由で、変更を修正しなければならなかったことはありませんか? 本番ソースを取り出して、以前のバージョンのコードがまだそこにテキスト形式で残っていることがわかっている場合は、複雑で難しい方法に頼る必要がないため、多くの時間を節約できます。バージョン管理ツールが提供する可能性のある「部分的なソースのマージ」および「部分的なソースの統合」を使用するプロセスを制御するため、非常にエラーが発生しやすくなります。

この現実を好まない人は、「完全に悪いわけではないが、完全に良いわけでもない」コードだけを作成することにキャリア全体を費やしてきたに違いありません。 . そして、後者を達成する可能性がどれほど大きいかは誰もが知っています。

version-control - コメントの古いコード

14 に答える 14

Related

Reference