We started using one for C# a while back, and discovered a couple key problems with it. First and foremost, sometimes its edits were not safe to do in the context - either that commented code really was important to keep around for some specific reason (e.g., it serves an explanatory purpose), or sometimes the changes were not truly behavior-neutral and would therefore introduce subtle bugs.
In light of that, I'm moving away from thinking that using tools like this as a sort of spray-on tan for cleaning up code is wise. I've started leaning toward the following approach: First, let sleeping dogs lie. Old messy code is like asbestos; it's most dangerous when you disturb it. Second, if you're going to have to work on the code anyway then that's an appropriate time to clean it up. Even so, proceed with caution: Make sure you understand the code and it's got good test coverage so you can visually and empirically verify that the cleanup isn't doing any damage.
It is a respectable point of view, but I think that automatize some boring tasks to correct inside the code is a good idea because let you work on other more interesting tasks.
In fact, most of us use some automatic ways to correct and enrich code with IDEs. Is it also incorrect? In fact, what we are trying to solve are the following situations:
a) In a context where there are a lot of developers and you have worked hard into improve the code style and someone else pushed code that again violates your "implicit" code style. Do you need to correct these bad practices over and over again?
b) There are some boring tasks that punctually appear like "refactoring" when deprecated methods appear or developers need to upgrade one external library version (eg. one critical bug appears).
We started using one for C# a while back, and discovered a couple key problems with it. First and foremost, sometimes its edits were not safe to do in the context - either that commented code really was important to keep around for some specific reason (e.g., it serves an explanatory purpose), or sometimes the changes were not truly behavior-neutral and would therefore introduce subtle bugs.
In light of that, I'm moving away from thinking that using tools like this as a sort of spray-on tan for cleaning up code is wise. I've started leaning toward the following approach: First, let sleeping dogs lie. Old messy code is like asbestos; it's most dangerous when you disturb it. Second, if you're going to have to work on the code anyway then that's an appropriate time to clean it up. Even so, proceed with caution: Make sure you understand the code and it's got good test coverage so you can visually and empirically verify that the cleanup isn't doing any damage.