Skip to main content

Programmers rarely preview automated refactorings

22 Jan 2012 - planet-eclipse

Most refactoring tools let the programmer preview the changes before applying the refactoring. Usually, a refactoring preview window has two parts: an overview of the affected parts of the code and views of the changes to each part. The overview gives a high-level summary of parts of the code that the refactoring will affect. The programmer can browse the overview to examine the changes that are going to affect each part of the code. The following figures show how the preview windows of Eclipse, IntelliJ, and NetBeans look like.

  screenshot of the Eclipse preview window for a Rename Field refactoring.

The Eclipse (3.7.1) preview window for a Rename Field refactoring

A screenshot of Extract Constant refactoring in the Quick Assist menu of

The Eclipse (3.7.1) preview of a refactoring selected in the Quick Assist menu

  screenshot of the IntelliJ preview window for a Rename refactoring.

The IntelliJ (11.0.1) preview window for a Rename refactoring

  screenshot of the NetBeans preview window for a Rename refactoring.

The NetBeans (7.1) preview window for a Rename refactoring

CodingSpectator recorded our participants' uses of the preview windows of the Eclipse refactoring wizards. Based on the data of CodingSpectator, the preview window got opened for only 2% of the refactorings that were performed using the refactoring wizard. Since the Eclipse refactoring tool sometimes forces the preview, our participants have opened the preview window for at most 2% of their automated refactorings. We also asked all of our interviewees who had used Quick Assist if they previewed their refactorings in the preview window of the Quick Assist menu. None of our interviewees had used the preview window of Quick Assist. These data show that our participants rarely previewed automated refactorings.

Some of our interviewees told us that they used the preview feature of the refactoring tool only when they were trying out a new automated refactoring. Based on our interviews, we found the following reasons for not using the preview window:

  1. Programmers are reluctant to use automated refactorings whose outcomes are hard to predict. If the automated refactoring is hard to predict and the programmers need to examine the preview closely, programmers are more likely to quit the tool and carry out the refactoring manually.
  2. Automated refactorings that programmers frequently use affect a small portion of the code and are easy to predict without previewing.
  3. The preview windows provide little useful context and too much information that overwhelms the programmers.
  4. Side-by-side views of code differences are not easy to read.
  5. When programmers perform a refactoring manually, they can evaluate the change gradually. However, if they use the preview window, there is a risk that they miss an important piece of change.
  6. It is an overhead to manage the preview windows. Programmers prefer to manage fewer windows and dialogs. Murphy-Hill et. al. had also reported that refactoring dialogs disrupt the programming workflow.
  7. Programmers are used to reading code in the source editor of the IDE because it provides many interactive features for browsing the code. The preview windows are not as interactive. Murphy-Hill et. al. had previously identified this problem with the preview window in a survey.

Predictability is an important factor in the adoption of a refactoring tool. However, the preview windows of current refactoring tools do a poor job of describing the refactorings. Perhaps we need to explore other means of making the refactoring tools more predictable. As our future work, we plan to improve the predictability of refactoring tools. Hopefully, programmers will use predictable refactoring tools more often, especially for performing bigger changes.