Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

closed as primarily opinion-based by gnat, Ixrec, GlenH7, Scant Roger, Bart van Ingen Schenau Jan 10 at 12:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This doesn't seem like a constructive question to me. It sounds more like a rant. – Rein Henrichs Apr 19 '11 at 22:52
I use them and I think you're right to use them. And I think the question will be closed very quickly... – Carl Manaster Apr 19 '11 at 23:04
Question as it is, not constructive. All answers are equally valid. If you ask "why wouldnt a developer use refactoring tools?" this could be answered with a list of good reasons. – P.Brian.Mackey Apr 19 '11 at 23:36
I am sorry if the question sounds like a rant - that was not my intent. I am genuinely interested in asking for some reasons why people don't use those tools. Finding out why could help us create better tools for instance if the problem lies with the user interface. I have tried to make it more concrete now by giving some reasons that me and my colleagues have come up with. – vazexqi Apr 19 '11 at 23:41
@Nick Unfortunately, that just makes the question even less on-topic. – user8 Apr 19 '11 at 23:50
up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
+1 search and replace is easy in most text editors. – Pemdas Apr 20 '11 at 2:03
I think this is an interesting perspective. I've encountered the limitations of the refactoring tools as you mentioned (especially with regards to tricky metaprogramming code in dynamic languages). For "normal" Java in Eclipse though, I find that I don't hit these limitations as frequently as such I'm comfortable using the tools. Can I surmise that if a programmer doesn't run into as many limitations, the programmer is more inclined to use them? And if a programmer keeps hitting the limitations, then the programmer would just quit using them? – vazexqi Apr 20 '11 at 4:35
@Pemdas Have you tried using search and replace with obfuscated code? Its very time consuming, especially with large code bases. – caffinatedmonkey Jul 28 '15 at 18:43

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.

share|improve this answer

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 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.

share|improve this answer
Interesting. I didn't realize there was this perceived bad-rep about programmers who overuse automated refactoring tools. I always thought that automated refactoring tools were underused but I guess they could also be overused in bad ways. Does this issue (bad rep from developers misusing the tool) prevent good developers from using the tool though? – vazexqi Apr 20 '11 at 6:34
You do refactoring manually? Really? – user1249 May 8 '11 at 9:46

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.

share|improve this answer
+1. This is indeed a current limitation of some tools. AFAIK, Eclipse and IntelliJ can handle such renames because they "understand" configuration files and other related files like *.xml, *jsp, etc. Some plugins are even smart enough to ensure that you follow the convention and configurations of the framework that you are using (ensuring empty constructors, ensuring getters and setters are named appropriately, etc). – vazexqi Apr 20 '11 at 16:19

I use an IDE to refactor code. It does a decent job, but gets it wrong sometimes. I also do whole codebase regex search and replace, and I often get them wrong too. I use my revision-control software (or diff) to show me what changed in the codebase. It happens often enough I check diffs now whenever I let my IDE do the refactoring.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.