JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

When Do Refactoring Tools Fall Short

Muhammad Taimur Khan and Javed Ferzund
AbstractRefactoring is the process of transforming code by preserving its behavior, to make it more maintainable and to improve its design. A particular refactoring is identified by a specific name, some preconditions and a set of needed transformations. Refactoring is a nontrivial and time consuming task because a lot of preconditions may need to be evaluated and transformations may affect a number of code locations. So, efficient and reliable tool development for refactoring is needed. A number of tools have been developed but analysis of these tools in terms of refactoring support and application to real projects is lacking. In this paper we present an empirical study to show the extent of refactoring provided by the major refactoring tools available to-date. We evaluate the performance of famous refactoring tools by applying them on large, real projects. It is found that most of the tools fall short in application of various refactoring types on large projects. Index TermsEmpirical Studies, Refactoring Tools, Software Metrics, Software Refactoring.

1 INTRODUCTION

OFTWARE maintenance is the most compromising phase in the software development life cycle. Most of the changes requested during this phase cause conflicts because new features or the rapid changes may not fit in the original design of the system, which may result in duplicate and ambiguous code. Software refactoring provides the solution to minimize the duplication and ambiguity in code and promotes the efficient handling of maintenance phase. Refactoring is used to improve the design and quality all the way through the software development lifecycle. It increases the developer performance by allowing her to easily catch and fix the bugs because source code is more readable. It supports extensibility by transforming the code into a recognizable pattern. Refactoring process consists of three major phases: a) In the identification phase, the source code to be re-factored is identified. It is the duplicated or bad code, which needs to be removed. The selected code is examined and analyzed to verify whether it is actually a bad/redundant code or not. b) In the proposal phase, selection of the refactoring candidate is made. Different candidates have different impact on the source code. This phase gives a list of refactoring candidates which will be applied on the source code to enhance the maintainability. c) In the evaluation phase, appropriate metrics are selected for evaluation of maintainability, reusability and understandability. These metrics are compared before and after applying the refactoring [8]. There are many different refactoring types having a particular purpose. Some of these techniques minimize redundancy of code, others improve level of abstraction. Some refactoring techniques can be applied to a group of programming languages; others can be applied to a certain type of language only. Commonly used refactoring techniques include: renaming the name of a class or the variable, accessing the field name with setter and getter methods, moving the code to super class, moving the code to a subclass, moving code from one method to another method

M. T. Khan is with the Department of Computer Science, University of Sargodha, Sargodha, Pakistan. J. Ferzund is with the Department of Computer Science, University of Sargodha, Sargodha, Pakistan.

for minimizing the complexity, and make generalization in the code for more sharing. Refactoring may change the internal structure of the body of the code but it does not alter the working of software. Every time a refactoring is applied to a piece of code, it transforms the code slightly reducing its redundancy or duplication. A sequence of refactoring is applied one by one in order to avoid any abrupt change in code. The changes made through the process of refactoring are so small that they are less likely to go false, but affect the source code significantly in a positive way [17]. Refactoring applied throughout the life cycle of software can improve the quality, maintainability, extensibility and reliability of code. Some studies have shown that refactoring activities do not always enhance the software quality but if applied in an ineffective way can deteriorate software quality [14]. Refactoring quality can be evaluated by examining the external quality attributes. Refactoring is successful if the correctness, robustness, compatibility, efficiency, portability and functionality of software is maintained [13]. Many developers hesitate to use refactoring, the reason being more manual amount of effort required for a minor change and increased chances of introducing bugs in the re-factored code. This problem can be solved by automated refactoring tools. A number of refactoring tools exist and modern IDEs also provide refactoring support such as IntelliJ IDEA [2], NetBeans [5] and Eclipse [1]. These IDEs provide special menu for refactoring in their menu bar. The developer can select the refactoring technique from the menu bar and apply refactoring on the selected code. Some refactoring tools like RefactorIt [6] and JRefactory [3] provide refactoring support for the whole source file and automatically recommend the refactoring according to different refactoring methods. These tools and IDEs provide refactoring in an effective and customized way but the refactoring engine should be reliable because refactoring process may introduce new bugs and can create uncertainty in the system. In this paper we analyze the refactoring support and evaluate the refactoring performance of various refactoring tools. Our objective is to evaluate the applicability of refactoring tools and suggest some guidelines for the design of future refactoring tools. We conduct an empirical study on

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

the source code of two large projects, Eclipse and JEditor. Five refactoring tools are evaluated in this study including Refactorit, JRefactory, Eclipse, IntelliJ IDEA, and NetBeans. Rest of the paper is organized as follows: in section 2, related work is discussed. A case study is presented in section 3, and results are discussed in section 4. Finally, the paper is concluded in section 5.

2 RELATED WORK
A number of studies exist on refactoring techniques, refactoring issues and tools for refactoring. Mens and Tourwe [13] in their survey on software refactoring focused on software activity to determine the appropriate level of abstraction in source code, design models or requirement document. The authors first identified the refactoring code portion and then measured the degree to which methods and variables of a class belonged together. During their behavior analysis in refactoring, they suggested that applications may be domain specific, real time software (execution time of certain operations, it should preserve all kind of temporal constraints), embedded software (memory and power issues solved by refactoring), safety critical software (safety that needs to be preserved). Garrido and Johnson [8] discussed the difficulties in refactoring C code with preprocessor directives. The authors defined preconditions and execution rules to maintain correctness of refactoring in the presence of macros and conditional directives. They proposed new refactorings for macro definitions and conditionals. Some enhancements were suggested for program analysis and program representation tools to correctly manipulate preprocessor directives. Henkel and Diwan [10] presented a lightweight approach for evolving application programming interfaces (APIs), which do not depend on version control or configuration management systems. Their approach was based on capturing the refactoring actions during API evolution. The authors provided an implementation of their approach to capture and replay refactoring actions within an integrated development environment. Savga and Heidenreich [15] discussed open issues of applying refactoring in the context of feature-oriented programming. The authors discussed impact of refactoring on the relation between the problem and solution spaces. They further suggested refactoring semantics to upgrade and test nal products of a product line. Soares et al. [17] presented a tool to identify behavioral changes in transformations. They tested their tool on 9 transformations and were successful in detecting all behavioral changes and not producing false alarms. Schfer et al. [16] analyzed changes in concurrent behaviors caused by refactoring engines and developed techniques to make them behavior preserving. The authors found that a broad range of refactorings are not inuenced by concurrency at all. Whereas other important refactorings could be made behavior-preserving for correctly synchronized programs by using their framework. The authors claimed that their techniques are easy to implement and require only minimal changes to existing refactoring engines.

Jemerov [11] described the key architectural components of IntelliJ IDEA involved in implementing refactorings. The author also described some of the problems faced when implementing refactorings and possible directions for future development. IntelliJ IDEA was the first to implement Extract Method refactoring for Java and later added support for a wide array of refactorings. Mens et al. [12] provided a detailed overview of existing research in the eld of software restructuring and refactoring, from a formal as well as a practical point of view. The authors proposed a list of open questions that indicated future research directions, and provide some partial answers to these questions as well. Murphy-Hill et al. [14] addressed the effect of method of data collection related to refactoring session on quality of results. The authors described 4 methods for drawing conclusions about how programmers refactor, characterized the assumptions made by each, and presented a family of experiments to test those assumptions. Glynn and Strooper [9] discussed some issues of refactoring related to level of automation, stages of the refactoring process, subset of the refactorings that could be applied and the complexity of refactorings. The authors presented a framework for evaluating software refactoring tool support based on the DESMET method. Our work is similar to the previous work, as we evaluate the extent and type of refactoring provided by various tools. However, previous studies lack empirical studies on the application of refactoring tools on large projects. We present a detailed evaluation of state of the art refactoring tools by applying these tools on large projects. We discuss the shortcomings of these tools and compare these tools for various types of refactoring.

3 CASE STUDY
In order to analyze the types and extent of refactoring provided by state of the art tools, we have designed an empirical study. For this study, five refactoring tools and source code of two large projects is selected. In this section, we discuss the refactoring feature available in different tools. Characteristics of source code and features of the projects are also discussed.

3.1 Refactoring Tools Five tools are used in this study including Refactorit, JRefactory, Eclipse, IntelliJ IDEA, and NetBeans. These tools are selected based on their popularity and easy availability. IntelliJ IDEA: It is the IDE (Integrated Development Environment) for java, which provides refactoring in its menu bar. The user selects the refactoring options from the menu bar and tool applies the refactoring on the selected code. So user manually applies refactoring on the source code. On the main refactoring menu or on the context menu of the selection the desired refactoring is chosen or the equivalent keyboard shortcut is pressed if there exist any. In the dialog box that opens the refactoring options, there is an option to apply the changes instantly, depending on the refactoring type. There is also support for previewing the changes before actually performing refactoring for certain refactoring.

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

IntelliJ IDEA provides the following common refactoring types: Change Class Signature, Change Method Signature , Convert Anonymous to Inner, Convert to Instance Method, Copy / Clone, Encapsulate Fields, Extract Delegate, Extract Include File, Extract Interface, Extract Method, Extract Method Object, Extract Superclass, Generify Refactoring, Inline, Introduce Constant, Introduce Field, Introduce Parameter, Introduce Parameter Object, Introduce Property, Introduce Variable, Invert Boolean, Make Class Static, Make Method Static, Migrate, Move Refactorings ,Pull Members Up, Push Members Down, Remove Middleman, Rename Refactorings, Replace Constructor with Builder, Replace Constructor with Factory Method, Replace Inheritance with Delegation, Replace Method Code Duplicates, Replace Temp With Query, Safe Delete, Type Migration, Use Interface Where Possible and Wrap Return Value. This vast support of refactoring options effectively removes redundant data and thus improves efficiency. Eclipse Refactoring: Eclipse is also the open source IDE for java. Refactoring commands are available from the context menu as well as in the menu bar. When the refactoring operations are applied one has the options to preview all of the changes that might occur when the refactoring operation would be performed. During this preview the tool provides information such as: Possible potential problems List/record of changes The list or record of changes includes the changes that will occur after applying the refactoring. In case we do not use the option of preview and perform the operations, the change will be applied as a whole and the problem resulting from that would be shown. In such case a kind of problem may occur that will prohibit the execution of the refactoring process thus resulting in halting of the operation displaying list of problems. So its a good approach to have a preview before applying a transformation. RefactorIT: It is a tool for Java developers. A developer can take source code of any size and complexity and rework it into welldesigned code by means of automated refactorings. It may be used as a stand-alone tool or installed as a plug-in. However, over the years RefactorIT lost market share because IDE's now offer built-in refactoring tools (first Ecplise and later also NetBeans). Today, there are still quite a few developers using it for their daily work. It is used for the audit and metrics of the code and it analyze the code and provides suggestion for the improvement of code design. JRefactory:

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

It is a tool that supports: move class between packages (repackage), rename class, add abstract parent class, add child class, remove empty class, extract interface, push up field, push down field, rename field, push up method, push up abstract method, push down method, move method, extract method, and rename parameter. This tool comes as a command line option with GUI or without, and as a plugin for the JEditor (still under development), JBuilder, NetBeans, and Elixir IDEs. For JBuilder and Elixir, you can switch from the UML diagram to the source code. Net Beans IDE: An open source Integrated Development Environment for software maintainers. It supports tools needed to create professional desktop, enterprise, web and mobile application with Java Platform ,C/C ++, PHP, Java Script and Groovy. Refactoring Operations include: Rename, Introduce variable, constant, field, or method, change method parameters, Encapsulate fields, Pull up, Push down, Move Class, Copy Class, Move Inner to Outer level, Convert Anonymous class to inner, Extract Interface, Extract super class, Use super type where possible, and safely delete.

3.2 Projects Used Two large open source projects are selected for this study: JEditor and Eclipse. Source code of these projects is checked out using Subversion. These projects are selected due to their large size and long development history. JEditor: JEditor 1.5 is a pure java editor (MDI). It provides some advanced features: open, save, save as, compile and run java source code. This version supports undo edits using stacks. It explains several uses of swings, threads, classes and stacks also. JEditor is downloaded from (http://www.planetsource-code.com). Eclipse: Source code of Eclipse is downloaded using Eclipse built in client for the Concurrent Versioning System (CVS).

4 RESULTS
We used software audits and calculated software metrics for both the projects. A software audit checks Java source code against a set of coding standard rules. Three types of metrics were calculated: simple metrics, object oriented metrics and quality metrics. A short description along with threshold values for the simple, object oriented and quality

TABLE 1 A DESCRIPTION OF SIMPLE METRICS

Simple Metrics Description CLOC V(G) DC EXEC Comment Lines of Code Cyclomatic Complexity Density of Comments CLOC/LOC Executable Statement It counts all lines that contain regular comments and java doc comments Counts the number of code conditions giving an indication of how complex program is This determines a density value for how commented code is This determines no of executable statements Lower Limit 0 1 .2 0 Upper Limit 10 10 .4 20

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG NCLOC Non Comments Line of Code This count all the lines that do not contain comments or blank lines NOP Number of parameter This count number of parameters for a method or constructor LOC Total Lines of code The number of lines for a class including blank lines and comments.

0 0 5

10 4 1000

TABLE 2 A DESCRIPTION OF OBJECT ORIENTED METRICS

Object Oriented Metrics Description A Ca DIT Ce Abstractness Afferent Coupling Depth in Tree Efferent Coupling This metric counts the ratio of abstract classes and interfaces for a package. Also known as Incoming Dependencies: This metric counts the number of classes from other packages that depend on classes in the analyzed package. This is the distance from the class to the root of the inheritance tree (0 for java.lang.Object).The preferred threshold values apply for a class. Also known as Outgoing Dependencies: This metric is a measure for the number of types of the analyzed package which depend upon types from other packages. The preferred threshold values apply for a package. Check to see how stable or instable your packages are designed. The preferred threshold values apply for a package. This metric counts the number of abstract classes and interfaces. The preferred threshold values apply for a package. This metric measures the number of direct subclasses of a class. The preferred threshold values apply for a class. This metric counts the number of concrete classes. The preferred threshold values apply for a package. This metric count the number of classes and interfaces exported outside a package. The preferred threshold values apply for a package. This metric counts the number of fields in a method (in local and anonymous classes).The preferred threshold values apply for a method. This metric count the number of classes and interfaces. The preferred threshold values apply for a package. This metric counts the number of distinct methods and constructors invoked by a class. The preferred threshold values apply for a class. This calculates the sum of cyclomatic complexity of methods for a class. The preferred threshold values apply for a class. This metric counts the number of fields in type (class or interface).The preferred threshold values apply for a class. Lower Limit 0.0 0 0 0 0.7 0 0 0 3 0 0 0 1 0 Upper Limit 0.5 500 5 20 1.0 20 10 80 50 1 80 50 50 5

I NOTa NOC NOTc NOTe NOF NOT RFC WMC NOA

Instability (I = Ce / (Ca + Ce)) Number of Abstract Types Number of Children in Tree Number of Concrete Types Number of Exported Types Number of Fields Number of Types Response for Class Weighted Methods per Class Number of Attributes

metrics is presented in Table 1, Table 2 and Table 3 respectively. The selected tools were unable to calculate the cyclomatic complexity and number of parameters metric for the Eclipse project, as indicated in Table 4. The only simple metrics calculated were related to lines of code.

The selected tools were able to calculate only the type related object oriented metrics for the Eclipse project. They failed to calculate the remaining object oriented metrics like WMC, RFC, DIT and NOC etc. The values for the calculated object oriented metrics for the eclipse project are presented in Table 5.

TABLE 3 A DESCRIPTION OF QUALITY METRICS

Quality Metrics Description CYC Cyclic Dependencies This estimates how many cycles in which a package is involved by determining the number of times a package is repeated in the dependency graph. The preferred threshold values apply for a package. This metric calculates the ratio of dependencies that have abstract classes or interfaces as a target to the total amount of dependencies for a class. The preferred threshold values apply for a class. A direct cyclic dependency for a package counts every mutual dependency: The number of other packages, the package depends on and which in turn also depend on the package. The preferred threshold values apply for a package.
2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

Lower Limit 0

Upper Limit 1

DIP

Dependency Inversion Principle Direct Cyclic Dependencies

0.3

1.0

DCYC

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG D Distance from the Main The perpendicular distance of a package from the main Sequence sequence from the idealized line A + I = 1. EP Encapsulation Principle This metric calculates the ratio of classes that are used outside of a package to the total amount of classes that the package contains.The preferred threshold values apply for a package. LCOM Lack of Cohesion of This is a measure for the cohesiveness of a class Methods (calculated using the Henderson-Sellers method). The preferred threshold values apply for a class. LSP Limited Size Principle The number of direct subpackages of a package.The preferred threshold values apply for a package. MQ Modularization Quality The MQ of a Module Dependency Graph (MDG) that is partitioned into k packages is the difference between the average inter- and intra-connectivity of the k packages. MQ is calculatable for the project node only, for the package nodes the intra-connectivity value is shown. NT Number of Tramps This metric counts the number of parameters in a class' methods, which are not used by its code.The preferred threshold values apply for a method.

0.0 0

0.1 0.6

0 0 0

0.2 10 1000

TABLE 4 SIMPLE METRICS FOR THE ECLIPSE PROJECT

Simple Metrics V(G) LOC 45290 NCLOC 29598 CLOC 11899 DC 0.263 NOP EXEC 2917

TABLE 5 OBJECT ORIENTED METRICS FOR THE ECLIPSE PROJECT

Object Oriented Metrics WMC NOC Ce Ca I A NOT NOTa NOTc NOTe NOF N O A

RFC

DIT

376

32

344

274

For the JEditor project, similar is the case for simple Among the quality metrics, the selected tools could calculate metrics. The selected refactoring tools were unable to only the modularization quality for the Eclipse project, as calculate the cyclomatic complexity and number of shown in Error! Not a valid bookmark self-reference.. The parameters metrics, as indicated in tools failed to calculate the remaining quality metrics like Table 7. distance from the main sequence, cyclic dependencies, and limited size principle etc. TABLE 6 QUALITY METRICS FOR THE ECLIPSE PROJECT
Quality Metrics D cyc DCYC LSP DIP EP MQ 80.295 NT LCOM

TABLE 7 SIMPLE METRICS FOR THE JEDITOR PROJECT

Simple Metrics V(G) LOC 948 NCLOC 771 CLOC 167 DC 0.176 NOP EXEC 300

TABLE 8 OBJECT ORIENTED METRICS FOR THE JEDITOR PROJECT

Object Oriented Metrics WMC NOC Ce Ca I A NOT NOTa NOTc NOTe NOF N O A

RFC

DIT

10

10

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

10

TABLE 9 QUALITY METRICS FOR THE JEDITOR PROJECT

Quality Metrics D cyc DCYC LSP DIP 0 EP 9 MQ 1.0 NT 0.0 LCOM 10

In case of object oriented metrics, more number of metrics are calculated for the JEditor project as compared to the Eclipse project. In addition to the type related metrics, afferent coupling, efferent coupling, instability and abstractness were also calculated by the selected tools, as shown in Table 8. It reveals that the refactoring tools fail to calculate these metrics for the large projects. Again for the JEditor project, more number of quality metrics was calculated as compared to the Eclipse project. In addition to the modularization quality, dependency inversion principle, encapsulation principle, number of tramps and lack of cohesion of methods were also calculated as shown in Table 9. It also reveals that the refactoring tools fail to calculate these metrics for the large projects, as size of the Eclipse project is much larger than the JEditor project.

When the whole source code of projects is selected, the behavior of different refactoring tools is different for the same projects. Table 10 shows different refactoring candidates for the Eclipse project. Second and third column of table indicate that refactoring behavior of RefactorIt and JRefactory is not similar. Both tools have almost 45% refactoring candidates in common but more than 50% refactoring candidates are different. Similarly, for the JEditor project 35% refactoring candidates are common and more than 60% candidates are different, as shown in Table 11. Less number of refactoring candidates is produced for the JEditor project as compared to the Eclipse project. Further, for the Eclipse project differences among the refactoring tools are more apparent. It reveals that for large projects the refactoring tools fail to produce optimal output.

TABLE 10 REFACTORING BEHAVIOR FOR THE ECLIPSE PROJECT

Refactoring Behavior Variable Related characteristics Not used member Found non-transient, non-static member. Please mark as transient or provide accessors Avoid variables with short names Avoid excessively long variable names like xmlCommentAttribute Unused assignment on variable Null parameter(s) Possible unsafe assignment to a non-final static field in a constructor Private field could be made final. It is only initialized in the declaration or constructor. Variables that are final should be in all caps Variables that are not final should not contain underscores (except for underscores in standard prefix/suffix). Initialization Related Characteristics Statements between declaration and first use early_declaration Avoid instantiating new objects inside loops Unused assignment on variable Private field could be made final. It is only initialized in the declaration or constructor The String literal 'target' appears 20 times in this file Avoid assigments in operands Avoid using 'while' statements without curly braces String "invalid XML file not imported: " was already used in this class, final string can be created. Switch statements should have a default label final field could be made static Avoid writing into array parameters such as 'result' If-else statements These nested if statements could be combined Deeply nested if..then statements are hard to read Avoid if (x != y) ..; else ..; If statement has no block Function Related Characteristics Empty block or body Method body has less than 2 statements Avoid calls to overridable methods during construction Method level Cyclomatic Complexity Unused method parameter When doing a String.toLowerCase()/toUpperCase() call, use a Locale A method should have only one exit point, and that should be the last statement in the method All methods are static. Consider using Singleton instead. Alternatively, you could add a private
2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

RefactorIT

JRefactory

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG constructor or make the class abstract to silence this warning Two strings compared with '==' operator -- expected str1.equals(str2) Method body has more than 20 statements Use block level rather than method level synchronization Class Related Characteristics A high number of public methods and attributes in an object can indicate the class may need to be broken up for exhaustive testing may prove difficult Each class should declare at least one constructor Abstract classes should be named 'AbstractXXX' Avoid unnecessary constructors Avoid instantiation through private constructors from outside of the constructor's class Avoid concatenating non literals in a StringBuffer constructor or append Cyclomatic Complexity of Class Avoid instantiating new objects inside loops A value of 73 may denote a high amount of coupling within the class Avoid really long Classes Avoid unnecessary constructors - the compiler will generate these for you Avoid calling toString() on String objects; this is unnecessary Package Related Characteristics A high number of imports can indicate a high degree of coupling within an object Unnecessary import statements Suggestion Interface Avoid using implementation types like 'HashMap'; use the interface instead Avoid using implementation types like 'Vector'; use the interface instead

11

TABLE 11 REFACTORING BEHAVIOR FOR THE JEDITOR PROJECT

Refactoring Behavior Variable Related characteristics Formed non transient, non static member (mark as transient or provide accesser) Variable with shorter name Avoid unused local variable Avoid method local variable with short name Avoid long variable name Variable that are not final should not contain under score Field name with method name Avoid concatenating with non literals Initialization Related Characteristics Avoid instantially string object Null Assignment to object If-else with out curly brackets Avoid loop with curly brackets Function Related Characteristics Method should have one exit point (It should be the last statement in methods. Method action performed has cyclic complexity of 15 Avoid to call overridable method during constructor Method is never overridden Class Related Characteristics Class should have one constructor Cyclomatic complexity Jeditor Complexity 04 Height 15 Value of 38 may denoted high amount of coupling with in class Jeditor 1.0 appears 04 times. RefactorIT JRefactory

Refactoring behavior in Refactor-It and JRefactory was not consistent. All refactoring candidates were not applied by these tools, only specific pattern was repeated during the refactoring process. Following output was obtained in different categories: Variable Related characteristics Avoid method local variable with short name Initialization Related Characteristics Null assignment to object Function Related Characteristics Should have only one exit point

Class Related Characteristics Class should have one constructor, Cyclomatic complexity

For the Net Beans IDE we found the following shortcomings: We cannot add new behavior in refactoring menu. When we change class name from upper case to lower case, Error is displayed first letter of class should be capital. When we apply the renaming in the source file renaming is not applied on the comment code which

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG 12 [8] A. Garrido, and R. Johnson, Challenges of Refactoring C may bring ambiguity in the source code which Programs, Proceedings of the International Workshop on consist of thousand lines of code. Principles of Software Evolution, IWPSE02, New York, USA, 2002. Extract Method which is very common in the [9] E. Glynn and P. Strooper, Evaluating software refactoring tool refactoring is not available in this version. support, Australian Software Engineering Conference, April 2006. We apply the refactoring manually, code is selected [10] J. Henkel, and A. Diwan, CatchUp! Capturing and replaying refactorings to support API evolution, International conference on and refactoring is applied from the menu bar. Software Engineering, ICSE05, pp 274-283, 2005. [11] D. Jemerov, Implementing Refactorings in IntelliJ IDEA, For the IntelliJ IDEA, following shortcomings were found: Proceedings of the 2nd Workshop on Refactoring Tools, WRT08, New refactoring type was not supported in this tool New York, USA, 2008. e.g. we cannot add new behaviors in these tools [12] T. Mens, S. Demeyer, B. Du Bois, H. Stenten, and P. Van Gorp, which can enhance the refactoring support. Refactoring: Current research and future trends, Electronic Notes in Theoretical Computer Science, Volume 82, Issue 3, December When we apply the renaming the class name 2003, Pages 483499. changes from A to a, and no warning is displayed [13] T. Mens, and T. Tourwe, A Survey of Software Refactoring, IEEE that class name should be capital. Transactions on Software Engineering, Vol 30, Issue 2, pp 126-139, Renaming is not applied in the comment code which 2004. increases ambiguity. [14] E. Murphy-Hill, A. P. Black, D. Dig, and C. Parnin, Gathering Refactoring Data: a Comparison of Four Methods, Proceedings of Refactoring is applied on the selected code and we the 2nd Workshop on Refactoring Tools, WRT08, New York, USA, cannot apply all of the supported refactoring once at 2008. a time. [15] I. savga, and F. Heidenreich, Refactoring in Feature-Oriented Extract methods during refactoring may bring more Programming: open Issues, In Proceedings of the Workshop on complexity which is difficult for understanding Modularization, Composition, and Generative Techniques for source. Product Line Engineering (McGPLE 2008). [16] M. Schfer, J. Dolby, M. Sridharan, E. Torlak, and F. Tip, Correct refactoring of concurrent Java code, In Proceedings of ECOOP 2010, pp 225249. 5 CONCLUSIONS [17] G. Soares, D. Cavalcanti, R. Gheyi, T. Massoni, D. Serey, and M. Cornlio, Safe Refactor Tool for Checking Refactoring Safety, in In this paper, we have presented an empirical study to tools session at SBES 2009, pp 49-54.

analyze the extent of refactoring provided by various refactoring tools. We evaluated the performance of famous refactoring tools by applying them on large, real projects. We tested five refactoring tools (IntelliJ IDEA, Eclipse Refactoring, RefactorIt, JRefactory, Net Beans IDE) on two large projects (Eclipse, JEditor).It is found that most of the tools fall short in application of various refactoring types on large projects. Software metrics are an important measure to identify the code to be refactored. The selected tools failed to calculate most of the object oriented and quality metrics. The number of failures was high for the larger project, in this case Eclipse. Refactoring behavior of different refactoring tools was not consistent. All refactoring candidates could not be applied by these tools, only a specific pattern was repeated during the refactoring process. New refactoring types were not supported in these tools. Renaming could not be applied on the commented code, which creates ambiguity. Manual selection of the refactoring candidates increases the time required for refactoring. It is more evident in the large projects. In future, we want to work on the design of refactoring tools.

Muhammad Taimur Khan received his MS Computer Science from University of Sargodha, Sargodha, Pakistan. He is working as a senior developer at the University of Sargodha, Pakistan. His research interests include Software Refactoring, Software Testing and Reverse Engineering Javed Ferzund received a Master degree in Computer Sciences in 2003 and a Doctor of Informatics from Technical University of Graz, Austria in 2009. His research interests include Software Maintenance & Evolution, Reverse Engineering and Software Debugging. He is currently an assistant professor at the Department of Computer Science and Information Technology, University of Sargodha, Pakistan.

REFERENCES
[1] [2] [3] [4] [5] [6] [7] Eclipse Refactoring, http://code.google.com/p/refactoringplugin/ IntelliJ IDEA, http://www.jetbrains.com/idea/ JRefactory, http://jrefactory.sourceforge.net/ JEditor, http://www.planet-source-code.com Net Beans, http://netbeans.org/ RefactorIt, http://refactorit.sourceforge.net/ M. Fowler, K. Beck, J. Brant, W. F. Opdyke, and D. Roberts, Refactoring: Improving the Design of Existing Code, AddisonWesley, 1999.
2012 Journal of Computing Press, NY, USA, ISSN 2151-9617