コメントアウトに反対する理由

多分、わざわざ書くまでもないことだと思う。
しかし、コメントアウトに関しては、慣習的に続けている人たちがいる。
自分もその人たちだった。でも、調べてみたらソースコードのコメントアウトについてあんまり書いてない・・・

まあ、ここら辺が調べたところ見つかった。

履歴管理はバージョン管理ソフトで行え！

ごもっとも、この一言に尽きます！

現行のバージョン管理システムはバックアップテープから、ソースを戻すので時間がかかるんだそうだ。
コメントアウト捨ててよし！

思っているところを書いてみる。

まず、短期的なコメントアウトは特に問題はないと思う。
といっても、３０分以内に試せるテスト用のコードとして、使うのがいいと思う。(ホスト系の環境では、ちょっとコンペアするだけでも３０秒以上の時間を消費してしまう。私の場合、いったんＰＣにソースを落としてから修正しているので問題なし。)

コメントアウト肯定派の人は、トラブルがあった際の戻しが楽であることを挙げる。
そんな危険なことはしないでほしい。
何度も修正があったソースはコメントアウト自体の可読性が悪くなっていることが多いからだ。
たとえば、修正履歴の入れ子。

//20090110 コメント変更
//if(flag){
//20090109 コメント変更
// Console.WriteLine("fo");
// Console.WriteLine("foo");
//}
//else
//{
// Console.WriteLine("ber");
//}
Console.WriteLine("ber");

２回目の修正、点がどのようなものであったか理解するのは難しい。
それを補うためかこんな書き方をしているソースも見たことがある。

//20090110 コメント開始
//if(flag){
// //20090109 コメント開始
// //Console.WriteLine("fo");
// //20090109 コメント終了
// //20090109 追加開始
// Console.WriteLine("foo");
// //20090109 追加終了
//}
//else
//{
// Console.WriteLine("ber");
//}
//20090110 コメント終了
//20090110 追加開始
Console.WriteLine("ber");
//20090110 追加終了

１行でよいソースが１７行だ。すばらしい。
これではますます、バックアップに頼ったほうが安全だ。

上記のソース修正の場合、こんな修正をしている場合がある。
この場合、インデントがずれるので、可読性がさらに悪くなる。

//20090110 コメント変更
//if(flag){
// //20090109 コメント変更
// //Console.WriteLine("fo");
// Console.WriteLine("foo");
//}
//else
//{
　 Console.WriteLine("ber");
//}

こんな感じでどんどん、可読性が下がる。
この場合、"コメントアウトしてから修正する"という慣習が、"動いているコードは触るな"という意味で使われたものだと思う。

あと実はソースコンペアツールにも問題がある。
実は、COBOLのコンペアツールはコメントアウト方式に最適化されている。
行数が減るとコンペアがうまくいかなくなることが多いので、削るに削れないらしい・・・