31日間ReSharper一周 Day 31: 安全な削除
2012-12-30 18:17:12
「31日間ReSharper一周」の31日目にようこそ(はいはい1日遅いですよ。昨日は休んだから)。
ネタにする最後のReSharperリファクタリングは「安全な削除」だ。Ctrl+Shift+Rメニューからでも、直接Alt+Delでも利用できる。
「安全な削除」は、また別のReSharperリファクタリングウィザードを表示する。最初のページ(大抵このページしか見ない)はかなりつまんない。まあそりゃ、何かを削除するのにそんなに何種類もやり方があるはず無いよね。
「安全な削除」の基本的な考えは、コードを壊さずに削除するということだ。次の2つのことをやってくれる。
- 問題が起きるかチェックする。メソッドを削除しようとしたときに、そのメソッドがどこかでまだ使われているならReSharperが警告するので、削除をキャンセルできる。ハイパーリンクのどれかをクリックすればコードにジャンプできるし、問題を全部「結果検索」ウィンドウに表示することもできる。
- 変更を完遂する。パラメータを削除する場合は全部の呼び出し元が更新されるだろう。仮想メソッドかインターフェースメソッドを削除する場合は、全子孫クラスからも削除するかどうか聞かれる。
「安全な削除」は、理論的には素晴らしい。コードが使われていないと思ったときに、実際使われていないことを確認し、それを削除し、全呼び出し元を更新するまでを1つの操作でできる。未使用パラメータについては手で確認する方法だってある。なぜならReSharperは、publicメソッドの未使用パラメータを確認したりしないから。ソリューションに含まれる全メソッドの全パラメータに対して「安全な削除」を手で動かすのは嫌だろうけど、何かが不適切ではないかと思った時にはいいクリーンアップツールだ。
ただ、この投稿のために調査しながら気づいたんだけど、ReSharperのチェックは完璧とは言いがたい。変更の完遂についてはかなりよくやってくれるようだが、最初に問題をチェックし通すことからはだいぶ離れている。だから……
注意の言葉
「安全な削除」の直前および直後には、いつもコンパイルすること。コードが壊れるかもしれないからだ。
1～2分探りまわって見つけた2つのケースは以下の通り。
- メソッドがデリゲートとして使われていて、そのメソッドのパラメータを「安全な削除」する場合は、ReSharperは止めない。その後はもう、メソッドは同じデリゲート型には明らかに一致しないから、コードはコンパイルできなくなる(メソッド全体を削除しようとしたときは警告してくれるから、少なくとも部分的にはデリゲートを意識しているんだろう)。
- もし別アセンブリのメソッド(たとえばSystem.Windows.Forms.Control.IsInputKeyとか)をオーバーライドしていて、メソッドからパラメータを「安全な削除」するのなら、ReSharperは先祖についての警告もなしにパラメータを削除するだろう。だからそのオーバーライドがコンパイルを通らなくなる。オーバーライドするメソッドと一致するシグネチャが無くなってしまうからだ。
いつでもコードが壊れると言いたいわけじゃない。それはありえない。注意してればなおさらだ(僕はイベントハンドラメソッドのパラメータを削除してみるほどバカじゃなかった。どうなるか知りたいとは思ったけども)。ほとんどの場合、ReSharperのチェックにひっかかるだろう。でもやっぱり前後にコンパイルしておいたほうがいい。