コメント内の古いコード[終了]

https://stackoverflow.com/questions/1022552

06-07-2019
|

質問

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

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

解決

SVNやCVSのようなものを使用する場合、いいえ。私はすぐにそれらを消去します。コードを読みにくくします。

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

他のヒント

考えられる正当な理由は、この（架空の）例です：

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

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

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

コードベースに古いコードを保持する理由は実際にはありません。邪魔になります。バージョン管理システムに各ファイルの履歴が表示されます。

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

時々、一時的な変更を加えていることを知ってコードをコメントアウトします（一時的には数日未満を意味します）。間違いなくそれに戻る予定です。

編集：別の関連するプラクティスは、ファイルに変更の名前と日付を入れることです：

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

これも行わないでください。誰が変更を行ったかを知ることは、当時は貴重に思えるかもしれませんが、時間が経つと、実際には価値がなくなり、コードが乱雑になります。

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

「どのくらいですか？」人々がまだ働いているホットスポットである場合、古いコードを1か2か所に置いても気になりません。

彼らはまだ新しいコードに自信を持っていないのかもしれません。新しいコードは「完了しましたか？」あるべき姿で書かれていますか？テストに合格しましたか？仕様にコメントして文書化されていますか？パフォーマンスは本来あるべき場所ですか？（古いコードと新しいコードの両方を使用することを考えることができる最良の理由は、特定のケースのタイミングまたはプロファイルを作成しているときです。）

新しいコードよりも望ましい古いコードについて何かありますか？

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

Sourcesafeが履歴を保持しているので、請負業者にコードをコメントアウトする必要がないことを思い出させるとき、彼らがなぜそれをしているのかを尋ねます。

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

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

はい、すぐにそれを壊します。それにコメントした開発者がそれを削除することについて確信を持っていなかったことを示す以外に価値はありません。または、ソース管理ソフトウェアの使用方法がわからない。

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

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

それ以外の場合、上記の選択肢は2つだけです。あなたの電話!!

古いコードを保持すると、コード全体を読むことが難しくなります。プロジェクトに何らかの形式のバージョン管理がある限り、コメント化されたコードは削除する必要があります。リビジョン管理がなく、セットアップできない場合は、コードベースの一部ではない場所に古いコードを配置することをお勧めします。

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

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

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

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

最初に、私はそれを取り除くと言います。

しかし、そうしない理由が1つあります。バージョン管理にはまだ存在しますが、だれでも見ることができるという意味ではありません。もう一度見る必要がある場合は、最初に存在したことを最初に知る必要があります。時々、将来の開発者が古い方法と新しい方法の両方を見る必要がある変更を加えますが、古い方法を削除すると、開発者はそれがかつて存在したことをどのように知ることができますか？ほとんどの人は、この種の問題に対してバージョン管理の変更を十分に文書化していない。

古いコードをそこに残す多くの理由。基本的に-一度削除されると効果的に消えます-誰かが実際にそこにいたことを覚えていない限りです。

悪意のある請負業者として、手順を大幅に書き直さない限り、コードを削除しません。それ。

私が現在紹介しているプロジェクトは、さらに別のアプローチを使用しています-ある種の妥協...コメントアウトし、（可能な場合-NetbeansやVisualStudioなどで）#region OLD_IMPLに古いコードを挿入します。効果？ -念のため、まだ古いコードがあります -未使用コードのブロックは正確に1行かかります（#region OLD_IMPL） -表示されている場合、そのコードは1年間使用されていません（コメントアウトの日付があります）。単純に削除できます。

重大な状況の場合、常にSVNを使用します;）

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

廃止されたコードを削除する必要がありますが、それが本当に本当に廃止されていることが確実にわかったら

「完全に悪いわけではなかったが、残念ながら完全ではない」ため、修正を修正する必要がありました。？まだ本番ソースを取り出して、以前のバージョンのコードがテキスト形式で残っていることを知っている場合、複雑で困難な手段に頼る必要がないため、多くの時間を節約できます。 -「部分的なソースマージ」を使用する非常にエラーの多いプロセスを制御します。および「部分ソース統合」バージョン管理ツールが提供する場合があります。

この現実を好まない人々は、「完全に悪いわけではないが、完全に良いことでもない」コードのみを作成するか、言い換えれば、完全に悪いコードのみを作成するというキャリア全体を費やしたに違いありませんまたは完全に完璧です。そして、私たちは皆、後者を達成する確率がどれほど大きいかを知っています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow