What deters developers from using automated refactoring tools?

Question

I was having a discussion with my colleagues about using the automated refactoring tools in IDEs (Eclipse, NetBeans, IntelliJ, Xcode, Visual Studio, etc) and was surprised that many of them were uncomfortable using such tools. One of them is a seasoned developer (Smalltalk, C/C++, Java, Javascript) for 20 years and he seldom uses an IDE and even when he does, he doesn't use the automated refactoring tools. He does a lot of refactorings, but he does them all by hand.

Personally, I rely a lot on refactoring tools. Whenever I work on a project, I try to pick an IDE that supports automated refactorings and use those refactorings whenever possible.

I am interested in finding out if professional developers here at Stack Exchange use automated refactoring tools. And, if you don't, why not?

To get things started, here are some reasons why my colleagues don't use the automated refactoring tools:

1. Trust - Sometimes they don't trust what the tool is doing especially if it is a complex refactoring like Pull-Up which might affect multiple files; they are worried that the tool might introduce subtle bugs.

2. Discoverability - Sometimes they don't even realize that such a refactoring is available in the IDE because it is not immediately obvious

3. Flexibility - Sometimes the tool is too rigid and they always feel like they have to configure it too much to get it to work the way they want.

Updated - summary

Based on the responses so far, I think I can summarize three things:

1. Developers don't have the time to try out all the different refactorings available. And because they can't try them out, they are suspicious of what they will do to the code (all the corner cases). This suspicion is warranted for production code under time pressure (even if you have tests to check). Perhaps better UI tools can alleviate this.

2. Developers have also been frustrated by the limitations of the refactoring tools especially when they use metaprogramming/reflection or have external files (xml, configuration, properties). Automated refactoring tools keep on improving but there will always be limitations. Sometimes the limitations are acceptable and other times they are not. I've spoken to several other colleagues and some of them are more tolerant of the limitations. For instance, if rename refactoring doesn't rename all the files but does a good job of renaming 90% of it, they are still happy to use the tool and fix up the remaining 10% by hand because it still saves time and effort.

3. [In my opinion from what I have gathered], developers feel that refactoring tools are nice-to-have features so if it doesn't work the first time (or does something unacceptable), they seem to be more incline to abandon them and make changes by hand. Compare this to other tools like compilers/debuggers which also have limitations and bugs. Developers are likely to stick with them despite their limitations because they are essential features that you can't just abandon in your workflow.

Thanks for all the responses. If this topic is of interest to more people, I suggest turning it into a Community Wiki.

It would be interesting to find out whether the size of the project, the availability of tests, the maturity of the IDE affect people's decision to use automated refactoring tools.

Answer 1

They're limited in what they can do, and often the results are less than satisfactory. Also, often they cover such obscure corner cases that they're not much useful to the majority of users.

In IntelliJ, I use part of the refactoring tools regularly (rename, change parameter list, extract method, etc.), while others I never use at all. Make static??? I try to avoid static like the plague. Change constructor to factory??? Never needed it.

In Eclipse, I rarely use any of them because they're IMO too clunky (but the more I use IntelliJ the more I loath Eclipse as a whole, so that may not be too surprising).

To directly address your points: 1) Trust. Indeed that can be a problem. I'd not use these tools on a codebase without knowing what they do so I can predict the results somewhat in advance. As the codebase gets larger, that gets harder to do (and the likelihood of the tool introducing bugs while working goes up, I've had it happen). 2) Discoverability. Very much so. Often they're hidden in multiple layers of context menus, and/or have very obscure names. 3) Flexibility. More often than being too inflexible, they're too flexible to be easy to use. Combined with frequently poor documentation that can leave you guessing as to what you're doing, not a good thing when working under time pressure (and who isn't constantly working under time pressure?).

So you'd want to take the time to experiment with the tools before employing them on production code, but most people (certainly the more senior people in a company) rarely have the time for such experimentation as they're already working more than full time on production code.

Answer 2

Refactoring tools, as with any tool, have limitations.

Limitations in the environments they run.

• Tell me about a command line refactoring tool.

Limitations in the kind of code it can refactor.

• Metaprogramming code often can't run through refactoring tools.

Limitations in the amount of support for different languages

• The quality of refactoring for Perl and Python a few years ago wasn't good. I don't know about now.

I've also found the few things I can do with automatic refactoring tools, I can do better with inline emacs macros. That's just my experience.

Answer 3

I can answer this because I am the guy you're talking about. Here's the thing. Refactoring is done to produce higher quality code. To do it right it requires quite a bit of thought. Yet refactoring tools make it exceedingly easy...to do something. So what happens? People refactor without thought leaving code that's worse than what was there to begin with. But you'll never convince the refactor tool whiz. Because refactoring is good--everyone knows it--and the IDE wizard did in fact refactor (eclipse said so). This isn't to say refactor tools are bad per se, but they get a bad name because of the type of programmer that tends to like them.

Answer 4

I think this is an interesting question because IDE's keep adding new features without getting enough feedback from their users. Such a question is a good way to provide some feadback from the programmers. The following is my personal experience with refactoring tools:

I use most of the refactoring tools of Eclipse but not all of them, because I don't know how they exactly work and what are their requirements on the code to be refactored.

Answer 5

Potential Refactoring Problems with MS VisualStudio (2005, 2008, 2010)

Note: To become more constructive I reinterprete your question as "Where must I be aware of potential propblems when using Refractoringtools"

If you are using some kind of reflection then Renaming Properties/Methods can become a nightmare because Renaming might not reflected in configuration/xml/gui-Files.

Unfortunately these Issuse only happens at runtime, not at compiletime.

This Issue happens with

• wpf/mvvm where xml/xaml/gui files have references to propertynames
• workflows where xml/xaml files have references to propertynames that control the workflow.

As long as there is no reflection based Programming (i.e. Winforms) Renaming with VS (or even VsExpress) works like a charme because it obeys Identifier Scope over several sub-Projects which is not the case with simple find and replace.