Using Continuous Change Analysis toUnderstand the Practice of RefactoringStas Negara Nicholas Chen Mohsen Vakilian Ralph E. Johnson Danny DigUniversity of Illinois at Urbana-Champaign{snegara2, nchen, mvakili2, rjohnson, dig}@illinois.eduAbstractDespite the enormous success that manual and automatedrefactoring has enjoyed during the last decade, we knowlittle about the practice of refactoring. Understanding therefactoring practice is important for developers, refactoringtool builders, and researchers. Many previous approaches tostudy refactorings are based on comparing code snapshots,which is imprecise, incomplete, and does not allow to an-swer research questions that involve time or compare manualand automated refactoring.We present the first empirical study that considers bothmanual and automated refactoring. This study is enabled byour novel algorithm, which infers refactorings from continu-ous changes. We applied this algorithm to the code evolutiondata collected from 23 developers working in their naturalenvironment for 1,520 hours. Using a corpus of 5,269 refac-torings, we reveal several surprising facts about how manualand automated refactorings are different. For example, somepopular automated refactorings are not representative whentaking into account manual refactorings. More than one thirdof the refactorings performed by developers are grouped. Forsome refactoring kinds, up to 42% of performed refactoringsdo not reach the Version Control System.1. IntroductionRefactoring [11] is an important part of software devel-opment. Development processes like eXtreme Program-ming [3] treat refactoring as a key practice. Refactoring hasrevolutionized how programmers design software: it has en-abled programmers to continuously explore the design spaceof large codebases, while preserving the existing behavior.Modern IDEs such as Eclipse [8], NetBeans [28], IntelliJIDEA [19], or Visual Studio [34] incorporate refactoring intheir top menu and often compete on the basis of refactoringsupport.Several researchers [6, 24–27, 33, 37] made strives intounderstanding the practice of refactoring. This is importantfor developers, refactoring tool builders, and researchers.Tool builders can improve the current generation of toolsor design new tools to match the practice. Understandingthe practice also helps researchers by validating or refutingassumptions that were previously based on folklore. It canalso focus the research attention on the refactorings that arepopular in practice. Last, it can open new directions of re-search. For example, we recently discovered that more thanone third of the refactorings performed in practice are ap-plied in a group, thus motivating new research into refactor-ing composition.The fundamental technical problem in understanding thepractice is being able to identify the refactorings that wereapplied by developers. There are a few approaches. One is tobring developers in the lab and watch how they refactor [25].This has the advantage of observing all code changes, so itis precise. But this approach studies the programmers in aconfined environment, for a short period of time.Another approach is to study the refactorings applied inthe wild. The most common way is to analyze two snap-shots of the code either manually [2, 6, 22, 23] or auto-matically [1, 5, 7, 17, 20, 30, 35]. However, the snapshot-based analysis has several disadvantages. First, it is impre-cise. Many times refactorings overlap with editing sessions(e.g., a method is both renamed, and its method body ischanged dramatically). Refactorings can also overlap withother refactorings (e.g., a method is both renamed and its ar-guments are reordered). The more overlap, the more noise.Our recent study [27] of 24 developers working for 1,652hours shows that 46% of refactored program entities are alsoedited or further refactored in the same commit. Second, itis incomplete. For example, if a method is renamed morethan once, a snapshot-based analysis would only infer thelast refactoring. Third, it is impossible to answer many em-pirical questions. For example, from snapshots we cannotdetermine how long it takes developers to refactor, and wecannot compare manual vs. automated refactorings.A much better approach is to study the refactoring prac-tice in the wild, while employing a continuous analysis.Refactoring tools like the ones in Eclipse record all auto-mated refactorings applied by a developer [6, 18]. Recentempirical studies about the practice of refactoring [26, 33]have used these recorded logs as the source of their analysis.But this approach does not take into account the refactoringsthat are applied manually. Others [25, 26, 33] have shownScope RefactoringAPI-levelEncapsulate FieldRename ClassRename FieldRename MethodPartially localConvert Local Variable to FieldExtract ConstantExtract MethodCompletely localExtract Local VariableInline Local VariableRename Local VariableTable 1. Inferred refactorings. API-level refactorings oper-ate on the elements of a program’s API. Partially local refac-torings operate on the elements of a method’s body, but alsoaffect the program’s API. Completely local refactorings af-fect elements in the body of a single method only.that programmers sometimes prefer to perform a refactoringmanually, even when the IDE provides an automated refac-toring.Our paper is the first empirical study that uses a contin-uous change analysis to study the practice of both manualand automated refactorings. We answer seven research ques-tions:1. What is the proportion of manual vs. automated refactor-ings?2. What are the most popular refactorings?3. Does a developer prefer to use automated refactoringsover manual ones?4. How much time do developers spend on manual vs. au-tomated refactorings?5. What is the size of manual vs. automated refactorings?6. How many refactorings are clustered?7. How many refactorings do not reach VCS?To answer these questions, we designed and imple-mented a novel refactoring inference algorithm that ana-lyzes code changes continuously. Currently, our algorithminfers ten kinds of refactorings performed either manuallyor automatically. These were previously reported [33] as themost popular among automated refactorings. Table 1 showsthe inferred refactorings, ranging from API-level refactor-ings (e.g., Rename Class), to partially local (e.g., ExtractMethod), to completely local refactorings (e.g., Extract Lo-cal Variable). The inferred refactorings cover a wide rangeof common refactorings, and we believe that our algorithmcan be easily extended to handle other refactorings as well.Our algorithm uses several refinements to infer refactor-ings: from fine-grained code edits (e.g., typing characters) itinfers Abstract Syntax Tree (AST) node operations, i.e., add,delete, and update AST node. From these, it infers high-levelNumber of participants Programming Experience (years)1 1 - 24 2 - 511 5 - 106 > 10Table 2. Programming experience of the participants.properties, e.g., replacing a variable reference with an ex-pression. From combination of properties it infers refactor-ings. For example, it infers that a local variable was inlinedwhen it noticed that a variable declaration is deleted, and allits references are replaced with the initialization expression.To group properties, our algorithm uses a dynamic slidingwindow.We applied our inference algorithm on the real code evo-lution data from 23 developers, working in their natural en-vironment for 1,520 hours.This paper makes the following contributions:1. We designed seven questions to understand the practiceof manual and automated refactoring.2. We designed, implemented, and evaluated a novel algo-rithm for inferring refactorings. To measure the precisionand recall of our inference algorithm, we sampled 16.5hours of code development which is approximately 1%of the whole dataset.3. We discovered several surprising facts about how man-ual refactorings differ from automated ones. For exam-ple, popular automated refactorings are not representa-tive when taking into account manual refactorings. Morethan one third of the refactorings performed by develop-ers are grouped. For some refactoring kinds, up to 42% ofperformed refactorings do not reach the Version ControlSystem.2. Research MethodologyTo answer our research questions, we employed the codeevolution data that we collected as part of our previous userstudy [27] on 23 participants. We recruited 13 ComputerScience graduate students and senior undergraduate sum-mer interns who worked on a variety of research projectsfrom six research labs at the University of Illinois at Urbana-Champaign. We also recruited 10 programmers who workedon open source projects in different domains, including mar-keting, banking, business process management, and databasemanagement. Table 2 shows the programming experience ofour participants1. In the course of our study, we collectedcode evolution data for 1,520 hours of code developmentwith a mean distribution of 66 hours per programmer anda standard deviation of 52.1 Note that only 22 out of 23 participants filled the survey and specified theirprogramming experience.To collect code evolution data, we asked each participantto install CODINGTRACKER [27] plug-in in his/her Eclipse IDE.During the study, CODINGTRACKER recorded a variety of evo-lution data at several levels ranging from individual codeedits up to the high-level events like automated refactoringinvocations and interactions with Version Control System(VCS). CODINGTRACKER employed CODINGSPECTATOR’s infras-tructure [33] to regularly upload the collected data to ourcentralized repository.At the time when CODINGTRACKER recorded the data, wedid not have a refactoring inference algorithm. However,CODINGTRACKER can accurately replay all the code editingevents, thus recreating an exact replica of the evolution ses-sion that happened in reality. We replayed the coding ses-sions and this time, we applied our newly developed refac-toring inference algorithm.We first applied our AST node operations inference al-gorithm [27] on the collected raw data to represent codechanges as add, delete, and update operations on the under-lying AST. These basic AST node operations serve as in-put to our novel refactoring inference algorithm. Section 4presents more details about our refactoring inference algo-rithm.Next, we answer every research question by processingthe output of the algorithm with the question-specific ana-lyzer.3. Research Questions3.1 What is the proportion of manual vs. automatedrefactorings?Previous research on refactoring practice either predomi-nantly focused on automated refactorings [24, 26, 33] ordid not discriminate manual and automated refactorings [6,37]. Answering the question about the relative proportionof manual and automated refactorings will allow us to es-timate how representative automated refactorings are of thetotal number of refactorings, and consequently, how generalare the conclusions based on studying automated refactor-ings only. Additionally, we will get a better insight about therefactoring behavior of developers.For each of the ten refactoring kinds inferred by ouralgorithm, we counted how many refactorings were appliedusing Eclipse automated refactoring tools and how many ofthe inferred refactorings were applied manually. Figure 1shows our results. The last column represents the combinedresult for all the ten refactoring kinds.Overall, our participants performed almost equal num-ber of manual and automated refactorings. Thus, researchfocusing on automated refactorings considers just a half ofthe total picture. Moreover, half of the refactoring kinds thatwe investigated, Convert Local Variable to Field, ExtractMethod, Rename Field, Rename Local Variable, and Re-name Method, are predominantly performed manually. Thisobservation undermines generalizability of the existing stud-Convert Loca l Variable to F ieldEncapsulate F ieldExtract Const antExtract Local VariableExtract Metho dInline Local V ariableRename Clas sRename FieldRename Loca l VariableRename Meth odOverall0%10%20%30%40%50%60%70%80%90%100%Manual AutomatedFigure 1. Relative proportion of manual and automatedrefactorings.ies based on the automated execution of these popular refac-torings. Also, it raises concerns for tool builders about theunderuse of the automated refactoring tools, which could bea sign that these tools require a considerable improvement.3.2 What are the most popular refactorings?Murphy et al. [24] and Vakilian et al. [33] identified the mostpopular automated refactorings to better understand how de-velopers refactor their code. We would like to get a morecomplete picture of the refactoring popularity by looking atboth manual and automated refactorings. Additionally, wewould like to contrast how similar or different are popu-larities of automated refactorings, manual refactorings, andrefactorings in general.To measure the popularity of refactorings, we employ thesame refactoring counts that we used to answer the previousresearch question. Figures 2, 3, and 4 correspondingly showthe popularity of automated, manual, and all refactorings.The Y axis represents refactoring counts. The X axis showsrefactorings ordered from the highest popularity rank at theleft to the lowest rank at the right.Our results show that the popularity of automated andmanual refactorings is quite different: the top five most pop-ular automated and manual refactorings have only two refac-torings in common – Rename Local Variable and RenameMethod, and even these refactorings have different ranks.The most important observation though is that the popularityof automated refactorings does not reflect well the popular-ity of refactorings in general. In particular, the top five mostpopular refactorings and automated refactorings share onlythree refactorings, out of which only one, Rename Method,has the same rank.Having a fuller picture about the popularity of refactor-ings, researchers would be able to automate or infer theExtract Local VariableRename Loca l VariableRename Clas sInline Local V ariableRename Meth odExtract Metho dEncapsulate F ieldRename FieldConvert Loca l Variable to F ieldExtract Const ant0100200300400500600700800Refactoring countFigure 2. Popularity of automated refactorings.Rename Loca l VariableRename FieldExtract Metho dRename Meth odConvert Loca l Variable to F ieldRename Clas sExtract Local VariableEncapsulate F ieldInline Local V ariableExtract Const ant020040060080010001200Refactoring countFigure 3. Popularity of manual refactorings.Rename Loca l VariableExtract Local VariableRename FieldExtract Metho dRename Meth odRename Clas sInline Local V ariableConvert Loca l Variable to F ieldEncapsulate F ieldExtract Const ant02004006008001000120014001600Refactoring countFigure 4. Popularity of refactorings.Convert Loca l Variable to F ieldEncapsulate F ieldExtract Const antExtract Local VariableExtract Metho dInline Local V ariableRename Clas sRename FieldRename Loca l VariableRename Meth od0510152025A = 0% 0% < A <= 25% 25% < A <= 50%50% < A <= 75% 75% < A < 100% A = 100%Number of participantsFigure 5. The degree of automated tool usage for each kindof refactoring.refactorings that are popular when considering both au-tomated and manual refactorings. Similarly, tool buildersshould pay more attention to the support of the popularrefactorings.3.3 Does a developer prefer to use automatedrefactorings over manual ones?In our previous study [33], we argued that developers mayunderuse automated refactoring tools for a variety of rea-sons, one of the most important being that developers aresimply unaware of automated refactoring tools. Answeringthis question will help us to better understand whether de-velopers who are aware about an automated refactoring toolprefer to use the tool rather than refactor manually.In the following, we denote the quantity of automated toolusage as A. We compute A as a ratio of automated refac-torings to the total number of refactorings of a particularkind performed by an individual participant. For each of theten of the inferred refactoring kinds, we counted the numberof participants who never use an automated refactoring tool(A = 0%), the number of participants who predominantlyrefactor manually (0% < A <= 25%), the number of partic-ipants who use an automated tool quite often, but still preferto refactor manually (25% < A <= 50%), the number ofparticipants who prefer to refactor using an automated tool,but still often refactor manually (50% < A <= 75%), thenumber of participants who predominatly use an automatedtool (75% < A < 100%), and the number of participantswho always use the automated refactoring tool (A = 100%).Figure 5 shows our results. The Y axis represents thenumber of participants. Every bar shows the number of par-ticipants in each of the six automated tool usage categories,A, for a particular refactoring kind.Our results show that for all refactorings, except RenameClass and Extract Constant, the number of participants whoalways perform the refactoring manually is higher than thenumber of participants who always perform the automatedrefactoring. Also, the fraction of participants who alwaysperform a refactoring manually is relatively high for all theten refactoring kinds. Overall, our results corroborate theprevious findings [26, 33] that the automated refactoringtools are underused.Another important observation is that for four refactoringkinds, Convert Local Variable to Field, Extract Constant,Extract Method, and Rename Local Variable, the number ofparticipants who are aware about the automated refactoring,but still prefer to apply it manually (0% < A <= 50%) ishigher than the number of participants who prefer to applythis refactoring automatically (50% < A <= 100%). Thisshows that some automated refactoring tools are underusedeven when developers are aware of them and apply themfrom time to time. Moreover, for all of the ten refactoringkinds, the number of participants who apply the automatedrefactoring only (A = 100%) is significantly lower thanthe number of participants who both apply the automatedrefactoring and refactor manually (0% < A < 100%).In particular, there are no participants who always applyConvert Local Variable to Field, Encapsulate Field, ExtractMethod, and Rename Field using the automated refactoringtools. These results show that developers are reluctant to useautomated refactoring tools, some more so than the others,which could be an indication of a varying degree of usabilityproblems in these tools.3.4 How much time do developers spend on manual vs.automated refactorings?One of the major arguments in favor of performing a refac-toring automatically is that it takes less time than performingthis refactoring manually [32]. We would like to assess thistime difference as well as compare the average durations ofdifferent kinds of refactorings performed manually.To measure the duration of a manual refactoring, weconsider all AST node operations that contribute to it. Ouralgorithm marks AST node operations that contribute toa particular inferred refactoring with the refactoring’s ID,which allows us to track each refactoring individually. Notethat a developer might intersperse a refactoring with othercode changes, e.g., another refactoring, small bug fixes, etc.Therefore, to compute the duration of a manual refactoring,we cannot subtract the timestamp of the first AST node op-eration that contributes to it from the timestamp of the lastcontributing AST node operation. Instead, we compute theduration of each contributing AST node operation separatelyby subtracting the timestamp of the preceding AST nodeoperation (regardless of whether it contributes to the samerefactoring or not) from the timestamp of the contributingAST node operation. If the obtained duration is greater thantwo minutes, we discard it, since it might indicate an inter-Convert Loca l Variable to F ieldEncapsulate F ield*Extract Const antExtract Local VariableExtract Metho dInline Local V ariableRename Clas sRename FieldRename Loca l VariableRename Meth od0510152025303540Manual AutomatedDuration (seconds)Figure 6. Average duration of performing manual refactor-ings and configuring automated refactorings. The black in-tervals represent the standard error of the mean (SEM). Theconfiguration time bar for Encapsulate Field refactoring ismissing since we do not have data for it.ruption in code editing, e.g., a developer might get distractedby a phone call or take a break. Finally, we sum up all thedurations of contributing AST node operations to obtain theduration of the corresponding refactoring.We get the durations of automated refactorings from COD-INGSPECTATOR [33]. CODINGSPECTATOR measures configurationtime of a refactoring performed automatically, which is thetime that a developer spends in the refactoring’s dialog box.Note that the measured configuration time does not includethe time that it takes Eclipse to actually change the code,which could range from a couple of milliseconds to severalseconds, depending on the performed refactoring kind andthe underlying code.Figure 6 shows our results. The Y axis represents theduration time in seconds. Note that the configuration timebar for Encapsulate Field refactoring is missing since we donot have data for this refactoring.We can compare durations of automated and manualrefactorings with a high statistical significance (p < 0.0005,using t-test ANOVA) only for Extract Local Variable, Ex-tract Method, Inline Local Variable, and Rename Class sincefor the other refactoring kinds our participants rarely usedthe configuration dialog boxes. The most time consuming,both manually and automatically, is Extract Method refac-toring, which probably could be explained by its complexityand the high amount of code changes involved. All otherrefactorings are performed manually on average in under15 – 25 seconds. Some refactorings take longer than others.A developer could take into account this difference whendeciding what automated refactoring tool to learn first.Convert Loca l Variable to F ieldEncapsulate F ieldExtract Const antExtract Local VariableExtract Metho dInline Local VariableRename Clas sRename FieldRename Loca l VariableRename Meth od110100Manual AutomatedSize (AST nodes)Figure 7. Average size of manual and automated refactor-ings expressed as the number of the affected AST nodes.The black intervals represent the standard error of the mean(SEM). The scale of the Y axis is logarithmic.Another observation is that Rename Field refactoring ison average the fastest manual refactoring. It takes less timethan the arguably simpler Rename Local Variable refactor-ing. One of the possible explanations is that developers per-form Rename Field refactoring manually when it does notrequire many changes, e.g., when there are few references tothe renamed field, which is supported by our results for thefollowing question.3.5 What is the size of manual vs. automatedrefactorings?In an earlier project [33], we noticed that developers tend toapply automated refactoring tools for small code changes.Therefore, we would like to compare the average size ofmanual and automated refactorings to better understand thisbehavior of developers.To perform the comparison, we measured the size of man-ual and automated refactorings as the number of the af-fected AST nodes. For manual refactorings, we counted thenumber of AST node operations contributing to a particularrefactoring. For automated refactorings, we counted all ASTnode operations that appear in between the start and the fin-ish refactoring operations recorded by CODINGTRACKER. Notethat all operations in between the start and the finish refac-toring operations represent the effects of the correspondingautomated refactoring on the underlying code [27].Figure 7 shows our results. The logarithmic Y axis repre-sents the number of the affected AST nodes.Our results show that for four refactoring kinds, ConvertLocal Variable to Field, Extract Method, Rename Field, andRename Local Variable, automated refactorings on averageaffect more AST nodes than manual refactorings with a highstatistical significance (p < 0.0005). One of the reasonscould be that developers tend to perform smaller refactoringsmanually since such refactorings have a smaller overhead.Another observation is that Extract Method is by far thelargest refactoring performed both manually and automat-ically – it is roughly three times larger than EncapsulateField, which is the next largest refactoring. At the same time,according to Figure 5, most of the developers prefer to per-form Extract Method refactoring manually in spite of thesignificant amount of the required code changes. This servesas an additional indication that the developers might not behappy with the existing automation of Extract Method refac-toring [25].3.6 How many refactorings are clustered?To better understand and support refactoring activities of de-velopers, Murphy-Hill et al. [26] identified different refac-toring patterns, in particular, root canal and floss refactor-ings. A root canal refactoring represents a consecutive se-quence of refactorings that are performed as a separate task.Floss refactorings, on the contrary, are interspersed withother coding activities of a developer. In general, groupingseveral refactorings in a single cluster might be a sign of ahigher level refactoring pattern, and thus, it is important toknow how many refactorings belong to such clusters.To detect whether several refactorings belong to the samecluster, we compute a ratio of the number of AST node op-erations that are part of these refactorings to the number ofAST node operations that happen in the same time windowas these refactorings, but do not belong to them (such oper-ations could happen either in between refactorings or couldbe interspersed with them). If this ratio is higher than a par-ticular threshold, T , we consider that the refactorings belongto the same cluster. We try to get as large clusters as possi-ble. The minimum size of a cluster is three. Note that forthe clustering analysis we consider automated refactoringsof all kinds and manual refactorings of the ten kinds inferredby our tool.Figure 8 shows the proportion of clustered and separaterefactorings for different values of T , which we vary from1 to 10. Figure 9 shows the average size of gaps betweenseparate refactorings (i.e., refactorings that do not belong toany cluster) expressed as the number of AST node opera-tions that happen in between two separate refactorings or aseparate refactoring and a cluster.Our results show that for T = 1, the majority of therefactorings are clustered. When the threshold grows, thenumber of the clustered refactorings goes down, but notmuch – even for T = 10, more than 35% of refactoringsare clustered. The average gap between floss refactoringsis not very sensitive to the value of the threshold as well.Overall, developers tend to perform a significant fraction ofrefactorings in batch mode. This observation emphasizes theimportance of researching refactoring clusters in order toidentify refactoring composition patterns.1 2 3 4 5 6 7 8 9 100%10%20%30%40%50%60%70%80%90%100%Clustered SeparateFigure 8. Proportion of clustered and separate refactoringsfor different values of the threshold T .1 2 3 4 5 6 7 8 9 10050100150200250300350400AST nodes countFigure 9. The average size of gaps between separate refac-torings expressed as the number of AST node operations.The X axis represents the values of the threshold T .3.7 How many refactorings do not reach VCS?Software evolution researchers [7, 9, 12–14, 21, 36] usefile-based Version Control Systems (VCSs), e.g., Git [16],SVN [31], CVS [4], as a convenient way to access the codehistories of different applications. In our previous study [27],we showed that VCS snapshots provide incomplete and im-precise evolution data. In particular, we showed that 37% ofcode changes do not reach VCS. Since refactorings play animport role in software development, in this study, we wouldlike to assess the amount of refactorings that never make itto VCS, and thus, are missed by any analysis based on VCSsnapshots.We consider that a refactoring does not reach VCS if noneof the AST node operations that are part of this refactoringreach VCS. An AST node operation does not reach VCS ifthere is another, later operation that affects the same node,up to the moment the file containing this node is commit-ted to VCS. These non-reaching AST node operations andrefactorings are essentially shadowed by other changes.Figure 10 shows the ratio of reaching and shadowedrefactorings. Since even a reaching refactoring might bepartially shadowed, we also compute the ratio of reachingand shadowed AST node operations that are part of reachingrefactorings, which is shown in Figure 11.Convert Loca l Variable to F ieldEncapsulate F ieldExtract Const antExtract Local VariableExtract Metho dInline Local V ariableRename Clas sRename FieldRename Loca l VariableRename Meth od0%10%20%30%40%50%60%70%80%90%100%Reaching refactorings Shadowed refactoringsFigure 10. Ratio of reaching and shadowed refactorings.Convert Loca l Variable to F ieldEncapsulate F ieldExtract Const antExtract Local VariableExtract Metho dInline Local V ariableRename Clas sRename FieldRename Loca l VariableRename Meth od0%10%20%30%40%50%60%70%80%90%100%Reaching changes Shadowed changesFigure 11. Ratio of reaching and shadowed AST node op-erations that are part of reaching refactorings.Our results show that for all refactoring kinds except Ex-tract Constant and Inline Local Variable, there is some frac-tion of refactorings that are shadowed. The highest shadow-ing ratio is for Rename refactorings. In particular, there aremore shadowed Rename Field and Rename Local Variablerefactorings than those that reach VCS. Thus, using VCSsnapshots to analyze these refactoring kinds might signifi-cantly skew the analysis results.Another observation is that even reaching refactoringsmight be hard to infer from VCS snapshots, since a notice-able fraction of AST node operations that are part of them donot reach VCS. This is particularly characteristic to Extractrefactorings, which have the highest ratio of shadowed ASTnode operations.4. Refactoring Inference Algorithm4.1 Inferring Migrated AST NodesMany kinds of refactorings that we would like to infer rear-range elements in the refactored program. To correctly infersuch refactorings, we need to track how AST nodes migratein the program’s AST. A node might migrate from a singlesite to another single site (i.e., this node is moved from oneparent node to another parent node), for example, as a re-sult of Inline Local Variable refactoring applied to a variablewith a single usage. Such migration is one-to-one migration.Also, a node might migrate from a single site to multiplesites, e.g., as a result of Inline Local Variable refactoring ap-plied to a variable with multiple usages in the code. Suchmigration is one-to-many migration. Finally, a node mightmigrate from multiple sites to a single site, e.g., as a result ofExtract Local Variable refactoring applied to an expressionthat appears in multiple places in the code. Such migrationis many-to-one migration.Figure 12 shows an example of Extract Local Variablerefactoring that results in many-to-one migration of the ex-tracted AST node. Figure 13 shows the effect of this refac-toring on the underlying AST. Note that the extracted ASTnode, string literal "-", is deleted from two places in the oldAST and inserted in a single place in the new AST – as theinitialization of the newly created local variable.Our refactoring inference algorithm takes as input a se-quence of basic AST node operations: add, delete, and up-date. The algorithm infers migrate operation from these ba-sic operations. A single migrate operation is composed ei-ther from one delete operation and one or more add or up-date operations, or from one add or update operation andone or more delete operations applied on the same AST nodewithin a specific time window. We consider that two ASTnodes represent the same node if they have the same ASTnode type and the same content. As a time window, we em-ploy a five minutes time interval.The algorithm assigns a unique ID to each inferred mi-grate operation. Note that a basic AST node operation canmake part of at most one migrate operation. The algorithmmarks each basic AST node operation that makes part of aparticular migrate operation with its ID. This allows to eas-ily establish whether two basic AST node operations belongto the same migrate operation in the following stages of ourrefactoring inference algorithm.4.2 Refactoring Inference Algorithm OverviewOur algorithm infers ten kinds of refactorings shown in Ta-ble 1. To infer a particular kind of refactoring, our algorithmlooks for properties that are characteristic to it. A refactor-ing property is a high-level semantic code change, e.g., ad-dition or deletion of a variable declaration. Figure 14 showsan example of Inline Local Variable refactoring and its char-acteristic properties: deletion of a variable declaration, dele-Attribute name DescriptionentityName The name of a program entityoldEntityName The old name of a program entitynewEntityName The new name of a program entitymigratedNode The migrated AST nodemigrateID The ID of the migrate operationparentID The ID of the parent nodedestinationMethodID The ID of the destination methodsourceMethodName The name of the source methodsourceMethodID The ID of the source methodgetterMethodName The name of a getter methodgetterMethodID The ID of the gettern methodsetterMethodName The name of the setter methodsetterMethodID The ID of the setter methodTable 3. Attributes of refactoring properties.tion of a variable reference, and migration of the variable’sinitialization expression to the former usage of the variable.Refactoring properties are identified directly from thebasic AST node operations that represent the actions of adeveloper. A developer may change the code in any order,e.g., first delete the variable declaration and then replace itsreferences with the initialization expression, or first replacethe references and then delete the variable declaration, etc.Consequently, the order in which the properties are identifieddoes not matter.A refactoring property is described with its attributes,whose values are derived from the corresponding AST nodeoperation. Table 3 shows 13 attributes that our algorithmemploys for a variety of refactoring properties. A propertymay contain one or more such attributes. Table 4 presentsrefactoring properties and their attributes. When the algo-rithm checks whether a property can be part of a particularrefactoring, the property’s attributes are matched against at-tributes of all other properties that already make part of thisrefactoring. As a basic rule, two attributes match if eitherthey have different names or they have the same value. Addi-tionally, the algorithm checks that the disjoint attributes havedifferent values: destinationMethodID should be differ-ent from sourceMethodID and getterMethodID shouldbe different from setterMethodID.Our algorithm combines two or more closely relatedrefactoring properties in a single refactoring fragment. Suchfragments allow to express high level properties that couldnot be derived from a single AST node operation, e.g., re-placing a reference to an entity with an expression involvestwo AST node operations: delete entity reference and addexpression. Table 5 shows the inferred refactoring fragmentsand their component properties.The algorithm considers that a refactoring is complete ifall its required characteristic properties are identified withina specific time window, which in our study is five minutes.Some characteristic properties are optional, e.g., replacingpublic String wrap(int num){ return "-" + num + "-";}public String wrap(int num){ String dash = "-"; return dash + num + dash;}Extract Local VariableFigure 12. An example of Extract Local Variable refactoring that results in many-to-one migration of the extracted AST node.BlockReturnStatement{return “-” + num + “-”;}AST of the old method bodyreturn “-” + num + “-”;InfixExpressionStringLiteralSimpleName“-” + num + “-”num“-”StringLiteral“-”AST of the new method bodyBlockReturnStatement{String dash = “-”;return dash + num + dash;}return dash + num + dash;InfixExpressionSimpleNameSimpleNamedash + num + dashnumdashSimpleNamedashVariableDeclarationStatementString dash = “-”;SimpleTypeStringVariableDeclarationFragmentdash = “-”SimpleNamedashStringLiteral“-”MigrateFigure 13. The effect of the Extract Local Variable refactoring presented in Figure 12 on the underlying AST.public int scale(int num){ int factor = 5; return factor * num;}public int scale(int num){ return 5 * num;}Inline Local VariableDeleted variable declarationDeleted variable referenceMigrated from variable initialization to usageFigure 14. An example of Inline Local Variable refactoring and its characteristic properties.Property name Property attributesAdded Entity ReferenceentityNameparentIDAdded Field AssignmententityNamesetterMethodIDAdded Field Declaration entityNameAdded Field ReturnentityNamegetterMethodIDAdded Getter Method DeclarationgetterMethodNamegetterMethodIDAdded Getter Method InvocationgetterMethodNameparentIDAdded Method DeclarationentityNamedestinationMethodIDAdded Method InvocationentityNamesourceMethodNamesourceMethodIDAdded Setter Method DeclarationsetterMethodNamesetterMethodIDAdded Setter Method InvocationsetterMethodNameparentIDAdded Variable Declaration entityNameChanged Entity Name In UsageoldEntityNamenewEntityNamesourceMethodNameChanged Field Name In DeclarationoldEntityNamenewEntityNameChanged Method Name In DeclarationoldEntityNamenewEntityNameChanged Type Name In ConstructoroldEntityNamenewEntityNameChanged Type Name In DeclarationoldEntityNamenewEntityNameChanged Variable Name In DeclarationoldEntityNamenewEntityNamesourceMethodNameDeleted Entity ReferenceentityNameparentIDDeleted Variable Declaration entityNameMade Field Private entityNameMigrated From MethodsourceMethodIDmigrateIDMigrated From UsagemigratedNodemigrateIDparentIDMigrated From Variable InitializationentityNamemigratedNodemigrateIDMigrated To Field InitializationentityNamemigratedNodemigrateIDMigrated To MethodentityNamedestinationMethodIDmigrateIDMigrated To UsagemigratedNodemigrateIDparentIDMigrated To Variable InitializationentityNamemigratedNodemigrateIDTable 4. Refactoring properties.Fragment name Component propertiesMigrated Across MethodsMigrated From MethodMigrated To MethodReplaced Entity With ExpressionMigrated To UsageDeleted Entity ReferenceReplaced Entity With GetterAdded Getter Method InvocationDeleted Entity ReferenceReplaced Entity With SetterAdded Setter Method InvocationDeleted Entity ReferenceReplaced Expression With EntityMigrated From UsageAdded Entity ReferenceTable 5. Refactoring fragments.field references with getters and setters in Encapsulate Fieldrefactoring is optional. Also, a refactoring might include sev-eral instances of the same characteristic property. For exam-ple, an Inline Local Variable refactoring applied to a vari-able that is used in multiple places includes several proper-ties of migration of the variable’s initialization expressionto the former usage of the variable. Even though it is suffi-cient to have a single instance of each required characteristicproperty to infer a refactoring, our algorithm infers a refac-toring as fully as possible, incorporating all properties thatbelong to it. If no more properties are added to a completerefactoring within two minutes, the algorithm considers thatthe inference of this refactoring is finished. Table 6 presentsthe characteristic properties of the ten refactorings inferredby our algorithm.4.2.1 Putting It All TogetherFigure 15 shows a high level overview of our refactoringinference algorithm. The algorithm takes as input the se-quence of basic AST node operations marked with migrateIDs, astNodeOperations. The output of the algorithm is asequence of the inferred refactorings, inferredRefactorings.The algorithm assigns a unique ID to each inferred refactor-ing and marks all basic AST node operations that contributeto a refactoring with the refactoring’s ID.The refactoring inference algorithm processes each basicAST node operation from astNodeOperations (lines 6 – 49).First, the algorithm removes old pending complete refactor-ings from pendingCompleteRefactorings and adds them toinferredRefactorings (line 7). A complete refactoring is con-sidered old if no more properties were added to it within twominutes. Also, the algorithm removes timed out pending in-complete refactorings from pendingIncompleteRefactorings(line 8) as well as timed out pending refactoring fragmentsfrom pendingRefactoringFragments (line 9). An incompleterefactoring or a refactoring fragment times out if it was cre-ated more than five minutes ago, i.e., the algorithm allocatesa five minutes time window for a refactoring or a refactoringfragment to become complete.Next, the algorithm generates refactoring properties spe-cific to a particular AST node operation (line 10). The kindinput: astNodeOperations // the sequence of basic AST node operations marked with migrate IDsoutput: inferredRefactorings1 inferredRefactorings = ;2 inferredRefactoringKinds = getAllInferredRefactoringKinds();3 pendingCompleteRefactorings = ;4 pendingIncompleteRefactorings = ;5 pendingRefactoringFragments = ;6 foreach (astNodeOperation ∈ astNodeOperations) {7 inferredRefactorings ∪= removeOldRefactorings(pendingCompleteRefactorings);8 removeTimedOutRefactorings(pendingIncompleteRefactorings);9 removeTimedOutRefactoringFragments(pendingRefactoringFragments);10 newProperties = getProperties(astNodeOperation);11 foreach (newProperty ∈ newProperties) {12 foreach (pendingRefactoringFragment ∈ pendingRefactoringFragments) {13 if (accepts(pendingRefactoringFragment, newProperty) {14 addProperty(pendingRefactoringFragment, newProperty);15 if (isComplete(pendingRefactoringFragment) {16 remove(pendingRefactoringFragments, pendingRefactoringFragment);17 newProperties ∪= pendingRefactoringFragment;18 break;19 }20 }21 }22 if (canBePartOfRefactoringFragment(newProperty) {23 pendingRefactoringFragments ∪= createRefactoringFragment(newProperty);24 }25 foreach (pendingCompleteRefactoring ∈ pendingCompleteRefactorings) {26 if (accepts(pendingCompleteRefactoring, newProperty) {27 addProperty(pendingCompleteRefactoring, newProperty);28 continue foreach line11; // the property is consumed29 }30 }31 foreach (pendingIncompleteRefactoring ∈ pendingIncompleteRefactorings) {32 if (accepts(pendingIncompleteRefactoring, newProperty) {33 newRefactoring = clone(pendingIncompleteRefactoring);34 addProperty(newRefactoring, newProperty);35 if (isComplete(newRefactoring) {36 pendingCompleteRefactorings ∪= newRefactoring;37 continue foreach line11; // the property is consumed38 } else {39 pendingIncompleteRefactorings ∪= newRefactoring;40 }41 }42 }43 foreach (inferredRefactoringKind ∈ inferredRefactoringKinds) {44 if (isCharacteristicOf(inferredRefactoringKind, newProperty) {45 newRefactoring = createRefactoring(inferredRefactoringKind, newProperty);46 pendingIncompleteRefactorings ∪= newRefactoring;47 }48 }49 }50 inferredRefactorings ∪= pendingCompleteRefactorings;Figure 15. Overview of our refactoring inference algorithm.Refactoring Properties/Fragments Optional Multiple instancesConvert Local Variable to Field Added Field Declaration no noDeleted Variable Declaration no noEncapsulate FieldAdded Getter Method Declaration no noAdded Setter Method Declaration no noAdded Field Assignment no noAdded Field Return no noMade Field Private no noReplaced Entity With Getter yes yesReplaced Entity With Setter yes yesExtract ConstantAdded Field Declaration no noMigrated To Field Initialization no noReplaced Expression With Entity no yesExtract Local VariableAdded Variable Declaration no noMigrated To Variable Initialization no noReplaced Expression With Entity no yesExtract MethodAdded Method Declaration no noAdded Method Invocation no noMigrated Across Methods no yesInline Local VariableDeleted Variable Declaration no noMigrated From Variable Initialization no noReplaced Entity With Expression no yesRename ClassChanged Entity Name In Usage yes* yesChanged Type Name In Constructor yes* yesChanged Type Name In Declaration no noRename Field Changed Entity Name In Usage no yesChanged Field Name In Declaration no noRename Local Variable Changed Entity Name In Usage no yesChanged Variable Name In Declaration no noRename Method Changed Entity Name In Usage no yesChanged Method Name In Declaration no noTable 6. Characteristic properties of the inferred refactorings. Note that at least one of the two optional properties of theRename Class refactoring, Changed Entity Name In Usage and Changed Type Name In Constructor, is required for thisrefactoring to be considered complete.of the AST node operation (add, delete, or update), the typeof the affected node (e.g., a variable declaration or reference,a method declaration, etc.), the context of the affected node(e.g., the containing method, the containing field or variabledeclaration, etc.), whether this operation is part of a migrateoperation – all are the factors that the algorithm accounts forin order to generate one or more properties shown in Table 4.In the following step, the algorithm processes the gener-ated properties one by one (lines 11 – 49). First, every newproperty is checked against each pending refactoring frag-ment (lines 12 – 21). If there is a refactoring fragment thataccepts the new property and becomes complete, then thisrefactoring fragment itself turns into a new property to beconsidered by the algorithm (line 17). Note that a refactor-ing fragment or a pending refactoring accepts a property ifthe property’s attributes match the attributes of the proper-ties that already make part of the fragment or the refactoring(more details on matching properties can be found in the pre-vious subsection). If the new property can be part of a newrefactoring fragment, the algorithm creates the fragment andadds it to pendingRefactoringFragments (lines 22 – 24).Next, the algorithm tries to add the new property to pend-ing complete refactorings (lines 25 – 30). If the new propertyis added to a complete refactoring, the algorithm proceeds tothe next new property (line 28).If there is no pending complete refactoring that acceptsthe new property, the algorithm checks whether this prop-erty can be added to pending incomplete refactorings (lines31 – 42). If an incomplete refactoring accepts the property,it is added to a copy of this incomplete refactoring (lines33 – 34). This ensures that the initial incomplete refactoringremains unchanged in pendingIncompleteRefactorings andthus, could be considered for future properties, if there areany. If adding the new property makes the new refactoringcomplete, it is added to pendingCompleteRefactorings (line36) and the algorithm proceeds to the next new property (line37). Otherwise, the new refactoring is added to pendingIn-completeRefactorings (line 39).If the new property does not make any of the pending in-complete refactorings complete, the algorithm creates newrefactorings of the kinds that the new property is character-istic of and adds these new refactorings to pendingIncom-pleteRefactorings (lines 43 – 48).Finally, after processing all AST node operations, thealgorithm adds to inferredRefactorings any of the remainingpending complete refactorings (line 50).4.3 Evaluation of Refactoring Inference AlgorithmTo evaluate our inference algorithm, we randomly sampled16.5 hours of code development from our corpus of 1,520hours (approximately 1%). Each sample is a 30-minutechunk of development activity, which includes writing code,refactoring code, running tests, committing files, etc. To es-tablish ground truth, the second author manually replayedeach sample and recorded any refactorings (of the ten kindsthat we infer) that he observed. He then compared this to thenumbers reported by our inference algorithm. The first andthe second authors discussed any observed discrepancies andclassified them as either false positives or false negatives.The confusion matrix for our inference algorithm is pre-sented below. The number of true negatives is representedas X . True negatives measure instances where a refactoringdid not occur. Since a refactoring could occur at any timeepoch (down to the last millisecond as recorded by our tool),there could be an enormous number of such true negatives.Our evaluation metrics do not depend on the number of truenegatives.Ground truthPositive Negative TotalInferenceAlgorithmPositive 42 7 49Negative 1 X 1 +XTotal 43 7 +XThe confusion matrix allows us to calculate two standardmetrics from information retrieval: precision and recall. In-tuitively, precision measures how many of the inferred refac-torings are indeed correct and recall measures how many ofthe refactorings were found by our inference algorithm. Ourinference algorithm has precision of 0.86 and recall of 0.97as calculated below.Precision =TruePositiveTruePositive+ FalsePositive=4242 + 7= 0.86Recall =TruePositiveTruePositive+ FalseNegative=4242 + 1= 0.975. Threats to Validity5.1 Experimental SetupWe encountered difficulties in recruiting a larger group ofexperienced programmers due to such issues as privacy,confidentiality, and lack of trust in the reliability of re-search tools. However, we managed to recruit 23 partici-pants, which we consider a sufficiently big group for ourkind of study.Section 2 shows that some participants used CODING-TRACKER for longer periods of time than the others. Also,some participants might be more prolific coders or applyrefactorings more often. Consequently, such participantsproduced a more significant impact on our results. At thesame time, we think that this non-uniformity is representa-tive of the real world.Our results are based on the code evolution data obtainedfrom developers who use Eclipse for Java programming.Nevertheless, we expect our results to generalize to similarprogramming environments.We infer only ten kinds of refactorings, which is a smallsubset of the total number of refactorings that a developercan apply. To address this limitation to some extent, weinferred those refactoring kinds that are the most popularamong automated refactorings [33].5.2 Refactoring Inference AlgorithmOur refactoring inference algorithm takes as input the ba-sic AST node operations that are inferred by another algo-rithm [27]. Thus, any inaccuracies in the AST node opera-tions inference algorithm could lead to imprecisions in therefactoring inference algorithm. However, we compute theprecision and recall for both these algorithms applied to-gether, and thus, account for any inaccuracies in the inputof the refactoring inference algorithm.Although the recall of our refactoring inference algorithmis quite high, the precision is noticeably lower. As a result,some of our numbers might be skewed. Nevertheless, webelieve that the precision is high enough not to undermineour general observations.To measure the precision and recall of the refactoringinference algorithm, we sampled around 1% of the totalamount of data. Although this is a relatively small fraction ofthe analyzed data, the sampling was random and involved 33distinct 30-minute intervals of code development activities.6. Related WorkTo accurately answer questions about the practice of refac-toring, we have to consider both manual and automatedrefactorings. Collecting information about automatic refac-toring is simple and can be done through instrumentingthe Eclipse refactoring infrastructure. Collecting informa-tion about manual refactorings, on the other hand, is morecomplex and relies on algorithms for inferring refactorings.This section summarizes state-of-the-art work in refactor-ing inference and empirical research of refactoring, and con-trasts our work to them.6.1 Automatic Inference of RefactoringsEarly work by Demeyer et al. [5] inferred refactoringsby comparing two different versions of source code usingheuristics based only on low-level software metrics (methodsize, class size and inheritance levels). To improve accuracy,subsequent work by other researchers described changesbetween versions of code using higher-level characteristicproperties. A refactoring is detected based on how well itmatches a set of characteristic properties. Our previous tool,RefactoringCrawler [7], used references of program entities(instantiation, method calls, type imports) as its set of char-acteristic properties. Weißgerber and Diehl [35] used names,signature analysis, and clone detection as their set of char-acteristic properties. More recently, Prete et al. [29] deviseda template-based approach that can infer up to 63 of the 72refactorings cataloged by Fowler [11]. Their templates buildupon characteristic properties such as accesses, calls, inher-ited fields, etc., that model code elements in Java. Their tool,Ref-Finder, infers the widest variety of refactorings to date.All these approaches rely exclusively on snapshots fromVCS to infer refactorings. Thus, the accuracy of detectiondepends on the closeness of the two snapshots being com-pared. We have shown in Section 3.7 that many refactoringsare shadowed and do not ever reach a commit. This com-promises the accuracy of inference algorithms that rely onsnapshots. Moreover, snapshot-based approaches (with theexception of Ref-Finder) usually concentrate only on API-level changes leaving out many of the completely or partiallylocal refactorings that we infer (see Table 1). This paints anincomplete picture of the evolution of the code.To address such inadequacies, our inference algorithmleverages fine-grained edits. Similar to existing approaches,our algorithm (see Table 6), infers refactorings by matchinga set of characteristic properties for each refactoring. Ourproperties consists of high-level semantic changes such asadding a field, deleting a variable, etc. In contrast to existingapproaches, our properties are precise because they are con-structed directly from the AST operations that are recordedon each code edit.In parallel with our tool, Ge et al. [15] developed Bene-Factor and Foster et al. [10] developed WitchDoctor. Boththese tools continuously monitor code changes to detect andcomplete manual refactorings in real-time. Although con-ceptually similar, our tools have different goals - we infercomplete refactorings, while BeneFactor and WitchDoctortry to infer and complete partial refactorings. While orthog-onal to our work on studying code evolution, these projectshighlight the potential of using refactoring inference algo-rithms based on fine-grained code changes to improve theIDE. In the following, we compare our tool with the mostsimilar tool, WitchDoctor, in more detail.Like our tool, WitchDoctor represents fine-grained codechanges as AST node operations and uses these operationsto infer refactorings. Although similar, the AST node op-erations and refactoring inference algorithms employed byWitchDoctor and our tool have a number of differences. Inparticular, our AST node operations inference algorithm [27]employs a range of heuristics for better precision, e.g., ithandles Eclipse’s linked edits and jumps over the unparsablestate of the underlying code. WitchDoctor specifies refactor-ings as requirements and constraints. Our refactoring infer-ence algorithm defines refactorings as collections of prop-erties without explicitly specifying any constraints on them.Instead, the properties’ attributes matching ensures compat-ibility of the properties that are part of the same refactor-ing (see Section 4.2). Additionally, our algorithm infers mi-grated AST nodes and refactoring fragments, which repre-sent a higher level of abstraction than properties that are con-structed directly from AST node operations. The authors ofWitchDoctor focused on real-time performance of their tool.Since we applied our tool off-line, we were not concernedwith its real-time performance, but rather assessed both pre-cision and recall of our tool on the real world data.6.2 Empirical Studies of Refactoring PracticeXing and Stroulia [37] report that 70% of all changes ob-served in the evolution of the Eclipse code base are express-ible as refactorings. Our previous study [6] of four opensource frameworks and one library concluded that more than80% of component API evolution is expressible throughrefactorings. These studies indicate that the practice of refac-toring plays a vital role in software evolution and is an im-portant area of research.Our paper focuses on studying software evolution throughthe lens of refactoring, juxtaposing both manual and auto-mated refactorings. Work on empirical research on the usageof automated refactoring tools was stimulated by Murphyet al.’s study [24] of 41 developers using the Java tools inEclipse. Their study provided the first empirical ranking ofthe relative popularities of different automated refactorings,demonstrating that some tools are used more frequently thanothers. Subsequently, Murphy-Hill et al.’s [26] comprehen-sive study on the use of automated refactoring tools providedvaluable insights into the use of automated refactorings inthe wild by analyzing data from multiple sources.Due to the non-intrusive nature of CODINGTRACKER, wewere able to deploy our tool to more developers for longerperiods of time. As such, we were able to infer and recordan order of magnitude more manual refactoring invocationscompared to Murphy-Hill et al.’s sampling-based approach,providing a more complete picture of refactoring in the wild.To compare manual and automated refactorings, Murphy-Hill sampled 40 commits from 4 developers for a total of175 refactoring invocations whereas our tool recorded 1,520hours from 23 developers for a total of 5,269 refactoringinvocations.Murphy-Hill et al.’s [26] study found that (i) refactoringtools are underused and (ii) the kinds of refactorings per-formed manually are different from those performed usingtools. Our data (see Section 3.3) corroborates both theseclaims. We found that some refactorings are performed man-ually more frequently, even when the automated tools ex-ists and the developer is aware of it. Due to the large differ-ences in the data sets (175 from Murph-Hill et al. vs. 5,269from ours), it is not possible to meaningfully compare theraw numbers of each refactoring kind. However, the generalconclusion holds: different refactoring tools are underused atdifferent degrees. Our work also builds upon their work byproviding a more detailed breakdown of the manual and au-tomated usage of each refactoring tool according to differentparticipant’s behavior.Vakilian et al. [32] observed that many advanced userstend to compose several refactorings together to achievedifferent purposes. Our results about clustered refactorings(see Section 3.6) provide empirical evidence of such prac-tices. Analyzing the actual elements that are affected by eachrefactoring would help us better understand both how theseclusters are formed and what are the implications of theseclustering behaviors on software evolution.7. ConclusionsThere are many ways to learn about the practice of refac-toring, such as observing and reflecting on one’s own prac-tice, observing and interviewing other practitioners, and con-trolled experiments. But an important way is always to ana-lyze the changes made to a program, since programmers’ be-liefs about what they do can be contradicted by the evidence.Thus, it is important to be able to analyze programs and de-termine the kind of changes that have been made. This istraditionally done by looking at the difference between snap-shots. In this paper, we have shown that sometimes snapshotshide information. A continuous analysis of change lets us seethat refactorings tend to be clustered, that programmers of-ten change the name of an item several times within a shortperiod of time, that extract method is performed more oftenmanually than automatically.Our algorithm for inferring change continuously can beused for purposes other than understanding refactoring. Weplan to use it as the base of a programming environmentbased on change. Continuous analysis is better at detectingrefactorings than analysis of snapshots, and it ought to be-come the standard for detecting refactorings.References[1] G. Antoniol, M. D. Penta, and E. Merlo. An automatic ap-proach to identify class evolution discontinuities. In IWPSE,2004.[2] J. Bansiya. Object-Oriented Application Frameworks: Prob-lems and Perspectives, chapter Evaluating application frame-work architecture structural and functional stability. 1999.[3] K. Beck and C. Andres. Extreme Programming Explained:Embrace Change (2nd Edition). Addison-Wesley Profes-sional, 2004.[4] CVS. CVS - Concurrent Versions System.http://cvs.nongnu.org/.[5] S. Demeyer, S. Ducasse, and O. Nierstrasz. Finding refactor-ings via change metrics. In OOPSLA, 2000.[6] D. Dig and R. Johnson. How do APIs evolve? a story ofrefactoring. Journal of Software Maintenance and Evolution:Research and Practice, 2006.[7] D. Dig, C. Comertoglu, D. Marinov, and R. E. Johnson. Au-tomated detection of refactorings in evolving components. InECOOP, 2006.[8] Eclipse. Eclipse IDE. http://www.eclipse.org/.[9] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, andA. Mockus. Does code decay? assessing the evidence fromchange management data. TSE, 2001.[10] S. Foster, W. G. Griswold, and S. Lerner. WitchDoctor: IDESupport for Real-Time Auto-Completion of Refactorings. InTo appear in ICSE, 2012.[11] M. Fowler. Refactoring: Improving the Design of ExistingCode. Addison-Wesley Longman Publishing Co., Inc., 1999.[12] H. Gall, M. Jazayeri, R. R. Klsch, and G. Trausmuth. Softwareevolution observations based on product release history. InICSM, 1997.[13] H. Gall, K. Hajek, and M. Jazayeri. Detection of logicalcoupling based on product release history. In ICSM, 1998.[14] H. Gall, M. Jazayeri, and J. Krajewski. CVS release historydata for detecting logical couplings. In IWMPSE, 2003.[15] X. Ge, Q. L. DuBose, and E. Murphy-Hill. Reconcilingmanual and automatic refactoring. In To appear in ICSE,2012.[16] Git. Git - the fast version control system. http://git-scm.com/.[17] M. W. Godfrey and L. Zou. Using origin analysis to detectmerging and splitting of source code entities. IEEE Transac-tions on Software Engineering, 31(2):166–181, 2005.[18] J. Henkel and A. Diwan. CatchUp!: Capturing and replayingrefactorings to support API evolution. In ICSE, 2005.[19] IntelliJIDEA. IntelliJ IDEA. http://www.jetbrains.com/idea/.[20] S. Kim, K. Pan, and E. J. Whitehead, Jr. When functionschange their names: Automatic detection of origin relation-ships. In WCRE, 2005.[21] M. M. Lehman and L. A. Belady, editors. Program evolution:processes of software change. Academic Press Professional,Inc., 1985.[22] M. Mattson and J. Bosch. Frameworks as components: aclassification of framework evolution. In NWPER, 1998.[23] M. Mattson and J. Bosch. Three Evaluation Methods forObject-oriented Frameworks Evolution - Application, Assess-ment and Comparison. Technical report, University of Karl-skrona/Ronneby, Sweden, 1999.[24] G. C. Murphy, M. Kersten, and L. Findlater. How Are JavaSoftware Developers Using the Eclipse IDE? IEEE Software,2006.[25] E. Murphy-Hill and A. P. Black. Breaking the barriers to suc-cessful refactoring: observations and tools for extract method.In ICSE, 2008.[26] E. Murphy-Hill, C. Parnin, and A. P. Black. How we refactor,and how we know it. In ICSE, 2009.[27] S. Negara, M. Vakilian, N. Chen, R. E. Johnson, and D. Dig.Is it dangerous to use version control histories to study sourcecode evolution? In To appear in ECOOP, 2012.[28] NetBeans. NetBeans IDE. http://www.netbeans.org/.[29] K. Prete, N. Rachatasumrit, N. Sudan, and M. Kim. Template-based reconstruction of complex refactorings. In ICSM, 2010.[30] F. V. Rysselberghe and S. Demeyer. Reconstruction of suc-cessful software evolution using clone detection. In IWPSE,2003.[31] SVN. Apache Subversion centralized version control.http://subversion.apache.org/.[32] M. Vakilian, N. Chen, S. Negara, R. Z. Moghaddam, and R. E.Johnson. Composite refactoring. In Under submission toOOPSLA, 2012.[33] M. Vakilian, N. Chen, S. Negara, B. A. Rajkumar, B. P. Bailey,and R. E. Johnson. Use, disuse, and misuse of automatedrefactorings. In To appear in ICSE, 2012.[34] VisualStudio. Visual Studio.http://www.microsoft.com/visualstudio/.[35] P. Weißgerber and S. Diehl. Identifying refactorings fromsource-code changes. In ASE, 2006.[36] Z. Xing and E. Stroulia. Analyzing the evolutionary historyof the logical design of object-oriented software. TSE, 2005.[37] Z. Xing and E. Stroulia. Refactoring practice: How it is andhow it should be supported - an eclipse case study. In ICSM,2006.

Interactive Software Refactoring Bot

Abstract

Extracted data

Interactive Software Refactoring Bot

Abstract

Extracted data

Related items

Related items