IntroductionRefactoring tools can play an important part in the refactoring process.

POSSIBLE CAUSES

activating refactorings fasterEmerson Murphy-Hill • Advisor: Andrew P. Black • {emerson,black}@cs.pdx.edu • Maseeh College of Engineering and Computer Science • Portland State University

INTRODUCTION AND PROBLEMS PROPOSED SOLUTIONS EVALUATION AND CONCLUSION

Refactoring CuesRefactoring Cues reverse the traditional select-then-initate refactoring style and make configuration optional.

Tools available at http://multiview.cs.pdx.edu/refactoring.This research supported by the National Science Foundation under CCF-0520346.

[1] Murphy, G. C., Kersten, M., and Findlater, L. How Are Java Software Developers Using the Eclipse IDE? IEEE Software. July 2006.[2] Murphy-Hill, E. Programmer-Friendly Refactoring Tools. Thesis Proposal. May 2007.[3] Murphy-Hill, E. Improving Usability of Refactoring Tools. OOPSLA Companion. October 2006.[4] Kurtenbach, G. and Buxton, W. User Learning and Performance with Marking Menus. SIGCHI 1994.

0

1

2

3 Treatment (median=7.5)

Control (median=3)

987654321

1 2

3 4

paletteOptionally, the programmer may begin by placing a palette adja-cent to program code containing all available refactorings.

selectionThe programmer then selects the program elements she wants to be refactored. Optionally, she may change configuration options in the expanded palette.

initiationWhen a programmer clicks a palette item, that item expands to reveal con-figuration options, and at the same time, all program elements applicable to the refactoring are highlighted in the editor.

post renameWhen the refactoring is executed, the palette is hidden, and the programmer is able to rename all newly created ele-ments in-line.

multi-element refactoringAny number of program elements can be refactored in one pass, without the need to repeatedly activate the tool.

optional configurationConfiguration is purely optional. In fact, the palette can be run in silent mode, where it is not displayed unless specifically requested.

non-modal configurationConfiguration is displayed beside the editor, so that the programmer can read the code being refactored and make intelligent configuration decisions.

error-resistant selectionOnly program elements that are applicable for a particular refactoring are selectable.

Sselect

Iinitiate

Cconfigure

Eexecute

standard toolsStandard wizard-based refactoring tools, such as the Eclipse environment, are used by selecting, initiating, configuring, then executing.

Iinitiate

refactoring cuesRefactoring cues are used by initiating, selecting, op-tionally configuring (C1), executing, then choosing newly created program element names (C2).

≤Refactoring Cues are at least as fast and accurate

as standard tools.

Sselect

Sselect

Sselect≤

A programmer can select in the same manner with Refactoring Cues as with standard tools, yet some mis-selections with the standard tool can be succesfully inferred with refactoring cues.

C1configure

Eexecute

C2configure

ConclusionI have formulated several guidelines to assist in the development of new refactoring tools.

Iinitiate

Iinitiate

=Either tool can be initiated with hotkeys, linear menus, or mark-ing menus. Refactoring Cues can also be activated through the palette.

Cconfigure

C1+2configure

≤Configuration with either tool need not be different, although if the programmer wishes to do no configuration, or simply config-ure the new element names, then C1 can by bypassed.

Eexecute

Eexecute

=Because the underlying refactor-ing engine is the same, and be-cause both tools are executed with a single hotkey or button press, both tools’ execution stages are equivalent.

Refactoring Cue EvaluationCan programmers select code quickly and accurately using Refactoring Cues?

eliminate errorsEliminate as many selection errors as possible by separating character-based selection from program-element selection. In other words, make anything that is selectable a valid input to the refactoring tool.

explicit regionsMake explicit what is refactorable before selection begins. The programmer shouldn’t have to wonder what she needs to select before using a refactoring tool. This guideline encourages design exploration.

no distractionInitiation should be fast enough to not distract the pro-grammer from the primary programming task, to which refactoring is subordinate.

utilize spatialityA refactoring initiation mechanism should leverage structural or spatial qualities of the refactorings, rather than the capricious names assigned to them.

stay in editorAvoid interrupting the programmer’s primary pro-gramming task. In most cases, this task takes place in the program editor.

no configurationAllow the programmer to bypass entering configura-tion information that she does not wish to enter.

future workI am in the process of building a family of refactoring tools that address different stages of the refactoring process. In doing so, I plan on deriving guidelines for better smell detection, transformation review, and error reporting.

evaluation methodHere I show how Refactoring Cues are at least as fast and accurate as standard tools. Further, I describe how Refactoring Cues are adventageous in certain significant use cases.

Subjective EvaluationDo programmers believe that refactoring marking menus and Refactoring Cues are usable?

methodologyIn an interview lasting about 20 minutes, I showed subjects screencasts of existing refactoring tools and the new tools in use. Rather than having subjects guess, I provided them a frank assessment of the ad-vantages and disadvantage of each tool. I then asked them about their likeliness to use the tool in the future.

subjectsFifteen subjects were recruited from the 2007 O’Reilly Open Source conference. Candidates were selected pseudo-randomly and were selected as inter-viewees only if they had recently used a programming environment with refactoring tools.

refactor moresame

marking menus

refactoring cues

question 1:If marking menus or Refactoring Cues were available in your daily development environment, would you use tools to refactor less often, more often, or the same amount?

question 2:If linear menus, hotkeys, marking menus and Refac-toring Cues were all available in your daily develop-ment environment, relatively how often would you use each to perform refactoring with tools?

1not at all

2 3 4 5frequently

refactoring cues

hotkeys

marking menus

linear menus

Pie Menu ExperimentCan refactoring menu items be placed memorably on marking menus?

methodologySubjects were asked to remember the location of 9 refactorings on 3 marking menus in about 5 minutes. Subjects were divided into two groups. In the control group, menu items were placed randomly. In the treat-ment group, menu items were placed according to my design rationale.

subjects8 programmers were recruited from a a PSU class on design patterns, 7 were recruited from PSU research assistants, and 5 were programmers from industry. Programmers were disqualified if they were familiar with this research or could not read Java code. In total, 16 subjects completed the experiment.

school

research

industry

Median difference between groups were statistically significant. (p=0.011 using Kruskal-Wallis ANOVA)

6 of 8 treatment subjects correctly extrapolated the location of a previously unseen refactoring.

Difference between marking menu and linear menu usage is statistically significant. (p=0.028, using a Wilcoxon signed ranks test)

Refactoring Marking MenusMarking menus [4] are like context menus, except that menu items are displayed radially.

fast initiationInitiating tools with marking menus is faster than with context menus. Rather than having to aim at a specific rectangular item area in linear menus, programmers need only gesture in a particular direction. Moreover, if the user already knows where the desired item is, she can make a selection before the menu is even drawn.

memorableWhen a user initates the same item repeatedly, muscle memory takes over. In other words, after repeated usage, a programmer intuitively knows how to initate a menu item. In this way, marking menus faciliate the transition from novice behavior to expert behavior.

design rationale of placementA programmers could only transition to expert behavior if they frequently execute many different refactorings. Unfortunately, programmers typically only execute a couple of refactorings frequently [4]. Therefore, I provide a design rationale of refactoring menu item placement which, I hypothesize, will help programmers remember the location of refactorings on marking menus without the need to frequently refactor. The three pieces of the design rationale are outlined below:

(1) directionalityRefactorings which have an intuitive directionality are placed in their natural direction. For instance, Pull Up Method is placed on the top and Push Down Field is placed on the bottom.

(2) inversesRefactorings which are inverses should be placed opposite one another. For instance, Extract Method is placed opposite Inline Method.

(3) similarityRefactorings which are similar are placed in the same location in different contexts. For instance, Inline Method is placed in the same location as Inline Local Variable.

Change Method Signature Alt+Shift+CExtract Local Variable Alt+Shift+LExtract Method Alt+Shift+MInline Alt+Shift+IMove - Refactoring Alt+Shift+VRename - Refactoring Alt+Shift+R

Code SelectionThe programmer typically chooses what should be refactored by selecting code.

Linear MenusOne way to initiate a refactoring tool is by using a system or context menu.

HotkeysOne way to initiate a refactoring is with a combination of key presses.

Refactoring WizardsA programmer usually configures a refactoring with a wizard or dialog box.

few usedAlthough hotkeys are theoretically a very fast way of initiating refactoring tools, practically programmers don’t use them much. According to Murphy and col-leagues’ long-term study of 41 programmers [1], the median number of hotkeys that programmers used was just 2. The maximum that any programmer used was just 5.

unmemorableCognitively, I believe that hotkeys are very hard to remember. This stems from the unintuitive multi-level mapping that a programmer must make: from the restructuring the programmer is thinking of, to a capri-ciously named refactoring, and finally to a hotkey mapping.

slow to navigateLinear menus take a significant amount of time to navigate. Linear menus are especially slow because the refactoring menu must compete with a multitude of other tools’ menus, or because there are many refac-torings available. Moreover, for refactorings than can be performed very quickly (such as inlining local vari-ables), it may be faster for the programmer to simply cut and paste than navigate the menu to the desired refactoring.

forced repetitionFor most refactoring tools, there is no way to refactor several program elements, such as inlining 3 local variables, without invoking the tool several times. Using Murphy and colleagues’ data [1], I have ob-served that at about half of refactorings occur as part of repeated refactoring tool use.

hard to selectAs I have shown previously, some code can be hard to select as input to a refactoring tool [3]. This is be-cause formatting may be unusual and because pro-gram statements and expressions can be arbitrarily long, sometimes spanning several screens.

compelled config.Users are forced to configure their refactoring, even when they don’t need or want to. In a recent small survey of Java users, eight programmers estimated about 75% of refactorings are performed without changing configuration options, except for the name of any newly created program entities.

work disruptionModal wizards or dialog boxes force the programmer to break focus on the code, disrupting their workflow. Moreover, the programmer is expected to make intel-ligent configuration choices while the code is partially obscured.

what is refactoring?Refactoring is the process of improving the structure of code without changing its behavior. Examples include Rename, Extract Method, and Inline Local Variable.

why is refactoring important?Despite the new terminology, refactoring simply describes what has been done for a long time. Ever since code has been structured, code has needed to be restructured. Because people do not have perfect foresight, refactoring allows a software design to change over time.

why refactoring tools?Refactoring tools automate what programmers would normally do by hand. In doing so, refactoring tools promise to transform code faster and with fewer errors than a programmer can do by hand.

problem: people underuse refactoring toolsIn a recent experiment with 16 upper level computer science students, only two had used refactoring tools in the past [2]. At the Agile Open Northwest 2007 conference, I surveyed 112 people about their usage of refactoring tools. The programmers, who should have been heavy refactorers by nature of the conference, reported that, on average, they opt not to use a refactoring tool when one is available 32% of the time [2]. Both results reveal under-usage of refactoring tools.

problem: tools are slowAt Agile Open Northwest 2007, I surveyed 28 programmers who spend at least 10 hours per week programming and have refactoring tools available at least 90% of the time they spend programming. Of those programmers, 40% reported that they sometimes did not use refac-toring tools because they could refactor faster by hand. I suspect that tools are too slow more often, both because programmers know that refactoring tools should be able to refactor faster, and because the programmers surveyed were refactoring enthusiasts.

ProblemsContemporary refactoring tools have two central problems.

Thanks to Andrew P. Black, Barry Anderson, Mark P. Jones, Andrea Faith Brandtner, the study participants, the anonymous reviewers for their insightful comments, and

the National Science Foundation for funding this research.

total refactorings placed correctly out of 9

subj

ect

coun

t