というルールがあって、だいたいどこでも最初のバージョンからずっと残ってて、
非常に読みづらい状態になっています。
この「修正部分をコメントで残す」というのは、よく見かけるコーディングルールだと思うのですが、
CVSなり、VSSなり、変更履歴はリポジトリで管理すればいいことで、
なぜわざわざ読みづらく、リファクタリングし辛いルールを設定するのか分かりません。
リポジトリ管理されている場合、修正部分をずっとコメントで残す規約に、何かメリットがあったら教えてください。
・歴史的経緯で残っているだけで、現在ではメリットはない、と私は思っています。
・関係者は自由に前のバージョンをリポジトリで閲覧できる前提とします。
・管理者はcvsが使えないから……というなら、ソースはもっと読めないはずです。
なので「修正する時、修正前のプログラムを忘れるかも」「歴史的経緯だけで、メリットはないです」「管理者はCVSを使えないから」という回答にはポイントをおつけできません。よろしくお願いします。
◆新規開発
開発段階を2つのフェーズに分けるとします
前半のフェーズでは、修正部分をコメントとして残す意味はないと思いますし、リファクタリングしずらいのでよくないと思います。後半に入って(結合?)テスト段階に入ったら、修正部分をコメントとして残すのは意味あることだと思いますし、自分自身に責任がないことを明確になるのでよいかなと思います。ソースレビューをするときにもソースを印刷するだけですみます。
◆追加開発
この場合は、どんなに醜いソースであっても、リファクタリングしないのが通例だと思います。また、前回の修正のソースのコメントが残っていても仕方がないことだと思います。
個人的に思っているのは、最新のソースに「そこが変更されたことがある」ということが書かれていないと、そもそも以前のバージョンの確認をしようと思わないからではないでしょうか?その結果、以前と同じミスを再度埋め込んでしまうかもしれない。
もちろん修正前に、その箇所が過去に何らかの修正を行ったかどうかを確認するというルールにすれば良いと思いますが、最近のバージョン管理ツールって、現在のソースの行数か何かを指定して、その部分の変更履歴を抽出する機能ってあるのですかね?(私が知らないだけ?)
最初から通しでの変更履歴が一覧できること、過去の変更に気づけること。
というのはたしかにメリットを感じます。
◆新規開発
開発段階を2つのフェーズに分けるとします
前半のフェーズでは、修正部分をコメントとして残す意味はないと思いますし、リファクタリングしずらいのでよくないと思います。後半に入って(結合?)テスト段階に入ったら、修正部分をコメントとして残すのは意味あることだと思いますし、自分自身に責任がないことを明確になるのでよいかなと思います。ソースレビューをするときにもソースを印刷するだけですみます。
◆追加開発
この場合は、どんなに醜いソースであっても、リファクタリングしないのが通例だと思います。また、前回の修正のソースのコメントが残っていても仕方がないことだと思います。
追加開発時に過去のコードを残しておくのは、責任範囲からも保守としても当然の措置かも。
たしかに納得感があります。
みんながみんな、ソース管理がキチっと出来ているわけじゃないっていうのが一番だと思います。
リポジトリ管理をしていない現場というのも(特に小規模なら)結構あります。
そんな状態なので、慣れているコメントでの管理の方が結果的に見やすくなる事が多いです。
例えば、コミットする際にコメントを残さなかったりする人間でも、コメントアウトする箇所には「○○の為コメントアウト」なんて書いていたり。
勿論これは悪い習慣ですが、なかなか全員の意識を変える事も出来ませんし、上の人間がそういう考えなら尚更…
私の経験での話なので、会社や現場の人員で相当左右されるとは思いますがね。
そういう環境での違いもあると思うんで、先輩やリーダーに一度聞いてみては?
いやあ、どっちかというと、私は年齢柄、先輩だったりリーダーだったりするので、
コードレビューをする側なのですが、規約に「コメントアウトで残せ」と書いてあっても、
「残す理由」が自分には見つからない現場というのが散見されます。
ただ、自分の視野が狭いだけかもしれないので、今回の質問に至りました。
リポジトリで管理してないなら、たしかに履歴を残す必要性は強く感じます。
あと、リポジトリ管理ソフトに慣れてない人が多い現場でもそうですね。
アメリカの会社で某ソフトウェア開発の現場にたずさわったことがあります。大規模ながらオールアセンブラーだと思ってください。ご存知のようにアセンブラでは「なにをしたいのか?」という意図が極めてわかりずらいです。なので、数行おきにコメントが入ってきます。それも行の後ろではなく、真ん中に入れていきます。修正が入るとやはり、その経緯を書いて行きます。(それと修正した人のショートネーム)
だんだん、仕様書部分が増え、コード自体が占める割合が減ってきます。ソースコードといっても、アルゴリズムを読んでいる感じでした。イメージとしてはwikiをよってたかって書き直してる感じですかね。
修正は修正IDが右端に入り、それで検索すると修正箇所すべてが分かるという形でした。
subversionのような管理はサブチームでは、やっていました。が、いわゆる「正規ライブラリー」はひとつしかバージョンをもっていませんでした。テストチームはかってにビルドしてましたから。
当然、開発が終了し、サポートチームに渡されるのは、ファイナルカットされたソースコードでした。
おそらくコメントをメモ程度に書いているのでは、おっしゃるとおりで何の役にも立たない気がします。日本でソースにコメントを書いているのも見かけますが、ほとんどが「メモ」程度でとてもじゃないですが、意図は分からないと思います。
ただ、現在、時々自分でプログラムを書いていてもそうですが、考え方を先に書いて、その間にソースコードを書くほうがラクに感じています。javadocみたいなのが好みです。
なので、まったく役に立たない歴史的遺物とは感じてないです。
えーと、コメントを書くこと残すこと自体は重大な意味があると思います。
また、履歴も「最終的に何を変更したいのか?」をコメントに書いてあるなら、
それを残すことは全然問題ないと思います。
私がもった疑問は、『古いコード自体』を、コメントアウトで残しておくことに、
どんなメリットがあるのか。ということです。
自分で書けない奴が、他からぱくってきたソースを切り貼りしてごまかしてるような場合に多いパターンです。
要するにあなたの経験してる現場にいるPGとSEがしょぼかっただけです。
普通ならコードレビューで教育的指導されるはずですが、それすらもしていないのでしょう。
まともな開発体制も制度も整ってない証拠です。
もっと程度の高いところに転職しましょう。
いやー、違うと思いますが。
コメントアウトしてソースを残すことと、切り貼りすることは関係ないと思います。
また、多くの場合、「修正前のソースを残すこと」はプロジェクトのコーディング標準に定められており、
コードレビューを厳密に実施すればするほど、修正前のソースが残ることになります。
伺いたかったことは「修正前のソースを残すこと」に私は、メリットが特に感じられないのですが、
何かメリットがあるのかどうか、ということです。
「修正部分をコメントで残す」というのは、コメントを書くということではなく、コメントアウト
しておくということなのですね。
私も基本的にはすべての修正部分を残すことにはあまり意味が無いと思います。
コードをコメントアウトして残す意味としては、デバッグやテスト用のコードなど
コメントを外しても動くことを確認している場合のみと思います。
これは修正部分ではなく、保守に必要な機能ですね。
ただ、過去の経験から修正部分をコメントアウトで残すパターンを思い出してみますと
インターフェースを維持するために関数を残していることがありました。
つまり元は何かの目的で作ったが、何らかの理由で使用しなくなった。
けれどもその関数をコールしているモジュールがたくさんあるので修正範囲を最小限にするために、
中身をコメントアウトしているという感じです。
その場合でも関係者には周知して、コードを残さずともコメントをしっかり書いてリポジトリ管理を
すれば良いとは思いますが、元々何をするつもりだったかを知らせるメリットはあるかもしれません。
いずれにせよ「修正部分」とルールでひとくくりするのではなく、使い分けが肝要と思います。
・・あまりメリットを書けていませんので、回答になってないと感じられたらポイントは結構です。
読み取っていただいたです。質問の意味が取りづらく、申し訳ないです。
不要になったモジュールを直す場合に、中身をコメントにして呼び出しても何も動作しないものとし、
呼び出し元は変更しない……ああ、希にありますね。そういうのも。
「場合によって使い分け」というのは考え方としては正しいと思うのですが、
おそらくコーディングルールを定める側は恣意的な運用がされるのを避けるため、
一律で「修正部分を残して直せ」というのかもしれません。
だんだん、そんな気がしてきました。
追加開発時に過去のコードを残しておくのは、責任範囲からも保守としても当然の措置かも。
たしかに納得感があります。