コメントアウトしたコードを消すことについて

Question

javaのプログラマーです。コメントアウトしたコードを消すことについてどう思いますか。引き継いだソースが汚く、コメントアウトしたコードがたくさんあり、また、ソースを整理すると使っていない変数、メソッド、クラスが沢山ありそれもコメントアウトしました。コメントアウトしたコードはgitで管理しているし、使い道もなさそうなですしソースも汚くなるので消したいのですが、やめた方がいいと言う意見があればご教示頂けないでしょうか。

Answer 1

不要になったコードを、実際に削除する代わりに コメントアウト する（しかも、ご丁寧に日付や担当者名、修正理由の案件管理番号などを付記する）やり方は、Gitなどのバージョン管理システムが登場するずっと前の手法を 盲目的に 踏襲しているだけの悪習です。

無用なコメントは、可読性 を損なうばかりではなく、バージョン管理システムを活用する上での最も基本となる 差分管理 を困難にする要因ともなります。

ですから、本来であれば 一掃 すべきです。中途半端に残すべきではありません。

しかしながら、無用な行の削除とはいえ、削除してしまうと 差分 が発生することには違いありません。ですので、無計画に削除してしまうと差分管理が面倒になってしまって、コードを整理するはずが 本末転倒 な状況になっていまします。

また、コメントの削除とはいえ、人間のやることですから思わぬミスが発生する可能性もゼロではありませんので、それなりの 確認（＝テスト） は必要と考えます。

ですので、実施するからには リファクタリング の実施に準じる形でそれなりの工数（＝コスト）を見込んできちんと実施すべきです。

つまり、以下のようなポリシーは厳守した方が良いと思います。

• 本来修正予定のないクラスやメソッドには不用意に手を加えない
• 修正予定のあるクラスやメソッドに関しては、削除予定のコメントのみを削除した状態で基本的なテストを実施し、挙動の変化の無いことを確認した上で一旦コミットする
• 必要なテスト工数を確保できない場合はコメント部分の削除は見送る

ただし、このような ソースを綺麗にする活動 は、それなりにコストも掛かりますし一人で実施しても効果が薄いので、プロジェクト全体としてのコンセンサスを得て、できれば全員の協力体制の下で実施すべきですね。

そういう観点からすると、ある程度以上大きく、しかも保守的なプロジェクトでは難しいかもしれません。

Comments

[katoy]

>> 必要なテスト工数を確保できない場合はコメント部分の削除は見送る
これがネックで、実施に踏み切れない事が多いと思います。

[pi-chan]

確かに仰る通りですね。ある程度の歴史のあるプロジェクトに共通の悩みだと思います。

しかし、より重要なことは、不要コードをコメントアウトするといった「誤った対応をした箇所を増やさない」事だと思います。

修正(削除)が無理ならば、せめて既に出来てしまった無意味なコメント部分は「塩漬け」にして決して触れない事が重要です。仮に殆ど同じコードを再度追加する必要があったとしても、塩漬け箇所は完全に無視して「新規の追加」とする事により、ある時点以降の差分管理は正しく実施出来るようになります。

お掃除も含めた「リファクタリング」は、あくまでも「品質改善」プロセスとして予算が取れる場合に、通常の開発プロセスとは明確に分けて実施すべきものだと考えます。

Answer 2

gitでソースを管理しているなら消してもいいのではと思います。明らかに、当面参照しないのがわかっているなら、可読性を下げる要因になりますし。
必要になればgitで履歴を参照できるので。

Answer 3

gitで管理しているし

というように、ファイルをバージョン管理しているのなら、私は不要なコードは積極的に削除すべきだと思います。

可読性を損なう、ファイルが無駄に大きくなるなど、デメリットしかないと考えるからです。

Answer 4

最新のソースコード上には、そのコードを理解する妨げになるようなノイズは除去すべきです。
バージョン管理システムでソースコードを管理していて、「プロジェクトのルールで、コメントを消すだけのコミットが許可されていない」ようなことが無ければ、消すべきだと思います。

できれば、まちがって消してはいけない部分をに消していないかをレビューしてもらうのが良いかも。

どうしても何かしら過去の情報をソースコード上に残したいのであれば、その旨を要約したコメントだけにして元のコメントを消したほうが良いと思います。

Answer 5

私はガンガン消していきます。

迷うとしたら一時的に消したという内容のコメントが付いていたときぐらいでしょうか。それでも確認した上で消しますが。

バージョン管理が普及する前はコメントアウトをして残していたそうですが、今はもう過去の話でしょう。

Answer 6

場合によりけり？

制御の世界で品質重視の物、たとえば人の命にかかわるような対象の場合は、コメントの削除もソースの改変として取り扱います。

この場合、コメントの削除など、広い意味でのソースの整理を行うためには、基のソースとの動作の変化がない事を確認する作業が必要になる事が多いです。運よく、整理前後のＨＥＸファイルが完全に同一だから動作確認をするまでも無いこともあるでしょうが、結構な確立で動作検証をやり直す事も多いです。

現状は、１世代分のみコメントを残すことが多いですね。（リスク管理のトレーサビリティマトリックスのタグをソースに書いておけ、とか言う面倒なルールがあるので） 次のバージョンアップの最初の作業で、それを消して、同一(動作）チェックしていますか・・・

ソースコード管理は便利ですが、チェック・バックアップ・履歴管理を効率化するだけで、整理後の動作にはほぼ無関係です。($Revision:とかでかく乱される事もありましたが…)

以上は、結構きつい分野の場合ですが、リスクレベルが低い分野なら、整理と必要があればその後の同一動作の試験を行うコストが許容できるなら、やった方が良いと思います。

Answer 7

引き継ぎを機に、コメントアウトされたコードは削除するとよいとおもいます。

参考情報：

• コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ https://codeiq.jp/magazine/2013/12/3700/

...
使わなくなった関数やステップをコメントアウトしてとって置くことがあります。
コメントアウトされたコードは、今のコードと関係のないものになっていることが多いです。
そのため、コードの可読性が著しく損なわれたり、grep検索にノイズとして引っかかって作業の妨げになったりします。
戻すことが当分ないと思ったら、思い切って削除してしまうことです。
削除された事実はSubversionやGitなどのバージョン管理システムで残すことができます。
いざとなれば、バージョン管理システムから復元することもできます。
ソースコードは「今」の状態を保つように心がけることが、読みやすいコードのカギです。
...

• 変更前をコメントアウトして残す習慣は未だ根強い http://irof.hateblo.jp/entry/20120815/p1

...
「バージョン管理ツールが使えない人にもわかるように」とか言われたこともありますが、そんなのに対して聞く耳を持ったら何も出来なくなるので放置でいいと思います。
...

Answer 8

自分は、たまたま自分が修正している部分で、絶対不要と分かっているのなら消します。
(修正履歴で、ここからここまで直しましたーって目印的なものは、プロジェクトのルールによりますが、即消します。)

でも、仕様調整によって一時的にコメントアウトしている部分も無きにしも非ずなので、
消す際も確認は必要だと思います。

そして、修正範囲外でコメントアウトしてある部分をガッツリ消すのはやりません。
コメントを消すということは、手を加えるということで、修正したということになり、
動作確認作業が大変になるからです。
触らぬ神に祟りなし、です。