Welcome to day 31 of my 31 Days of ReSharper. (Okay, so it’s a day late. I took yesterday off.)
The last ReSharper refactoring I’m going to cover is Safe Delete. It’s accessible through the Ctrl+Shift+R menu, or directly via Alt+Del.
Safe Delete brings up another of ReSharper’s refactoring wizards. The first page (which, in many cases, is the only page you even see) is pretty boring, since there really aren’t that many different ways to delete something.
The general idea of Safe Delete is that it will delete something without breaking your code. It does two things:
Checks for problems. If you try to delete a method, and that method is still used somewhere, ReSharper will warn you, and give you a chance to cancel the delete. You can click one of the hyperlinks to jump to the code, or you can show all the problems in the Find Results window.
Carries the changes through. If you delete a parameter, all the call sites will be updated. If you delete a virtual method or an interface method, you get asked if you want to delete it from all the descendant classes as well.
Safe Delete is fabulous in theory: if we suspect code is unused, we can confirm that it’s not used and delete it and update all the call sites in a single operation. It even gives us a way to manually check for unused parameters, since ReSharper doesn’t bother checking for unused parameters in public methods. You wouldn’t want to manually run Safe Delete on every parameter of every method in your solution, but when you suspect something’s amiss, it’s a good cleanup tool.
But as I found while I was researching this post, its checks are far from perfect. It seems to do pretty well at carrying the changes through, but it’s got a ways to go on checking for problems first. So:
A word of caution
Always compile just before, and again just after, you use Safe Delete. Because it can break your code.
Here are a couple of cases I found in just a minute or two of poking around:
If a method is used as a delegate, and you Safe Delete a parameter, ReSharper will let you. After that, obviously it doesn’t match the same delegate type anymore, so the code won’t compile. (They will warn you if you try to delete the entire method, though, so they’re at least partly delegate-aware.)
If you’re overriding a method from another assembly (e.g., you’re overriding
System.Windows.Forms.Control.IsInputKey), and you Safe Delete a parameter from your method, ReSharper will delete the parameter without warning you about the ancestor. So the override won’t compile anymore, since there’s nothing with a matching signature for it to override.
I don’t mean to suggest that it’s always going to break your code. Far from it, especially if you’re paying attention. (I knew better than to try deleting a parameter of an event-handling method, I just wanted to see what it would do.) Its checks will catch you in most cases. But it’s still a good idea to compile before and after.