Integrating "Code Smells" Detection with Refactoring Tool Support

Refactoring is a form of program transformation which preserves the semantics of the program. Refactoring frameworks for object-oriented programs were first introduced in 1992 by William Opdyke. Few people apply refactoring in mainstream software development because it is time consuming and error-prone if done by hand. Since then, many refactoring tools have been developed but most of them do not have the capability of analyzing the program code and suggesting which and where refactorings should be applied. Previous work discusses many ways to detect refactoring candidates but such approaches are applied to a separate module. This work proposes an approach to integrate a "code smells'' detector with a refactoring tool. To the best of our knowledge, no work has established connections between refactoring and finding code smells in terms of program analysis. This work identifies some common analyses required in these two processes. Determining which analyses are used in common allows us to reuse analysis information and avoid unnecessary recomputation which makes the approach more efficient. However, some code smells cannot be detected by using program analysis alone. In such cases, software metrics are adopted to help identify code smells. This work also introduces a novel metric for detecting "feature envy''. It demonstrates that program analysis and software metrics can work well together. A tool for Java programs called JCodeCanine has been developed using the discussed approach. JCodeCanine detects code smells within a program and proposes a list of refactorings that would help improve the internal software qualities. The programmer has an option whether to apply the suggested refactorings through a "quick fix''. It supports the complete process allowing the programmer to maintain the structure of his software system as it evolves over time. Our results show that restructuring the program while trying to preserve its behavior is feasible but is not easy to achieve without programmer's declared design intents. Code smells, in general, are hard to detect and false positives could be generated in our approach. Hence, every detected smell must be reviewed by the programmer. This finding confirms that the tool should not be completely automated. An semi-automated tool is best suited for this purpose