A Study on Code Smell Detection with Refactoring Tools in Object Oriented Languages

A Study on Code Smell Detection with Refactoring Tools in Object Oriented Languages

• 1.
  Integrated Intelligent Research(IIR) International Journal of Business Intelligents Volume: 05 Issue: 01 June 2016 Page No.38-40 ISSN: 2278-2400 38 A Study on Code Smell Detection with Refactoring Tools in Object Oriented Languages S.James Benedict Felix1 , Viji Vinod2 1 Research Scholar, Bharathiar University, Coimbatore,Tamil Nadu, India. 2 Professor & Head, Department of Computer Applications,Dr.MGR Educational and Research Institute University,Chennai , India. Email:x.brothers@live.com,vijivino@gmail.com Abstract-A code smell is an indication in the source code that hypothetically indicates a design problem in the equivalent software. The Code smells are certain code lines which makes problems in source code. It also means that code lines are bad design shape or any code made by bad coding practices. Code smells are structural characteristics of software that may indicates a code or drawing problem that makes software hard to evolve and maintain, and may trigger refactoring of code. In this paper, we proposed some success issues for smell detection tools which can assistance to develop the user experience and therefore the acceptance of such tools. The process of detecting and removing code smells with refactoring can be overwhelming. Keywords: Code Smells, Refactoring, Success Factors I. INTRODUCTION The development of Object Oriented Programming, the number of software analysis tools available for detecting bad smells significantly rise. Code smells are a method of giving names to these software design problems. A code smell is an uneasily written code that breaches software design principles. Refactoring and smell detection are both widely maintained by various tools for almost every recent programming language. II. DETECTION OF CODE SMELL The following requirements should be fulfilled to detect code smells from source code. First, all syntax information of source code should be represented. Second, it should be easy to access and extract semantic information from denoted source code model. Lastly, it should be simple to extract relational information between classes. [1] Code smells are defined in two ways. Primitive smell: Smell can be identified from one class Derived smell: Derived smell can be discovered from relations between classes 2.1Common Code Smells The following bad smells are in Object Oriented Programming Languages given by Fowler et.al [2]. Duplicated code: It means that the same code structure appears in more than one place. Long method: It is a method that is too long, so it is difficult to understand, change, or extend. Large class: It means that a class is trying to do too much. These classes have too many instances, variables or methods. God class: It generally called also design flaw, refer to class that tends to centralize the intelligence of the system. Long parameter list: A long list of parameters in a procedure or function make readability and code excellence worse. Feature envy: It means that a method is more interested in other class than the one where it is currently located. This method is in the wrong place since it is more tightly coupled to the other class than to the one where it is currently located. Contrived complexity: Forced usage of excessively complicated design patterns where simpler design would suffice. Complex conditionals: Branches that check lots of unrelated conditions and edge cases that don't seem to capture the meaning of a block of code. Primitive obsession: The smell represents a case where primitives are used instead of small classes. Switch statement: The smell means a case where type codes or runtime class type detection is used instead of polymorphism. Data clumps: the smell means that software has data items that often appear together. Temporary fields: The smell means that class has a variable which is only used in some situation. Refused bequest: The smell means that a child class does not fully support all the methods or data it inherits. Lazy class: It means a class that is doing nothing enough and should be removed. Data class: a class that contain data, but hardly any logic for it. Middle man: It means that a class is delegating most of its tasks to subsequent classes. Divergent change: The smell means that one class needs to be constantly changed for different reasons. III. REFACTORING Software refactoring [3] is a procedure of altering a software system in such a way that it does not change the external behavior of the code, and amends its internal structure. Refactoring is measured a best practice in creating and maintaining software, and research suggests that programmers practice it frequently. The term refactoring was introduced by Opdyke[4] in the year 1990. The basic idea of software refactoring can be drew back to restructuring i.e. the transformation of one representation form to another, while preserving the system‘s external behavior. Refactoring is becoming very popular owing to lightweight development procedures such as extreme programming that advocate constant refactoring. Refactoring is basically the object - oriented variant
• 2.
  Integrated Intelligent Research(IIR) International Journal of Business Intelligents Volume: 05 Issue: 01 June 2016 Page No.38-40 ISSN: 2278-2400 39 of restructuring. In the evolution of software restructuring and refactoring are used to increase the quality of the software in terms of extensibility, reusability, and maintainability. Refactoring is a kind of method to develop program performance which includes program performance, structure, maintenance, and appearance without any changes to its original functionality. Refactoring is usually initiated/invoked by the developer. Most software developers only refactor their code when it is certainly necessary because this process requires in-depth knowledge of the software system. 3.1 Tools for the automatic detection of code smell [5] Most of the tools are not capable to perform refactoring automatically on detecting smells (JDeodorant is the only one which provides refactoring choices), but modern IDEs are usually capable of performing the refactoring automatically, also if they need user guidance. Checkstyle: Checkstyle has been developed to help programmers write Java code that follows to a coding standard. It is capable to detect the Large Class, LongMethod, Long Parameter List, and Duplicated Code code smell. DECOR: Moha et al. defined an approach that permits the specification and automatic detection of code and design smells (also called antipatterns). They stated six code smells by using a custom language, automatically generated their detection algorithms using templates, and validated the algorithms in terms of precision and recall. This style is implemented in their Decor platform for software analysis. inFusion: It is the current, commercial growth of iPlasma. inFusion is able to detect more than 20 design errors and code smells, like Duplicated Code, classes that break encapsulation, i.e. Data Class and God Class, Classes and Methods that are heavily coupled, or ill-designed class hierarchies. iPlasma: This tool is an incorporated platform for quality assessment of object-oriented systems that includes support for all the essential phases of analysis, from model extraction, up to high-level metrics based analysis. iPlasma is capable to detect what the authors define as code disharmonies, classified into identity disharmonies, collaboration disharmonies, and classification disharmonies. The detailed description of these disharmonies can be found in. Many code smells are considered as disharmonies, e.g., Duplicated Code (named Significant Duplication), God Class, Feature Envy, and Refused Parent Bequest. JDeodorant: It is an Eclipse plugin that automatically recognizes the Feature Envy, God Class, Long Method and Switch Statement (in its Type Checking variant) code smells in Java programs. The tool helps the user in defining an applicable sequence of refactoring applications by defining the possible refactoring transformations that solve the identified problems, ranking them according to their impact on the design, presenting them to the developer, and automatically applying the one selected by the developer. PMD: PMD scans Java source code and looks for potential problems or possible bugs like dead code, empty try or catch or finally or switch statements, unused local variables or parameters, and duplicated code. PMD is capable to detect Large Class, Long Method, Long Parameter List, and Duplicated Code smell, and permits the user to set the threshold values for the exploited metrics. Stench Blossom: Stench Blossom is a smell detector that offers a cooperative visualization background designed to give programmers a quick and high level outline of the smells in their code, and of their source. The tool is a plugin for the Eclipse environment that offers the programmer with three different views, which gradually offer more information about the smells in the code being visualized.The feedback is artificial and visual, and has the figure of a set of petals close to a code element in the IDE editor. The size of a petal is directly proportionate to the “strength” of the smell of the code element it refers. The only possible procedure to find code smells is to manually browse the source code, looking for a petal whose range is big sufficient to build the user suppose that there is a code smell. The tool is able to detect eight smells. JSNose: JavaScript code smell detection system called JSNOSE. Our metric-based approach combines dynamic and static analysis to detect smells in client-side code. This automated technique can assistance developers to spot code that could benefit from refactoring. JCosmo: It contains of two main phases: the code smell extraction and the visualization. During extraction, the source code is parsed and a model of source is generated that defines the program structure and code smells. This source model is read during visualization to generate different views on the source code and its smells. FxCop: FxCop is a free static code analysis tool from Microsoft that checks .NET be able to code assemblies for conformance to Microsoft's .NET Framework Design Guidelines. Unlike StyleCop, or the lint programming tool, for the C programming language, FxCop considers the compiled object code, not the original source code. It uses CIL parsing, and callgraph analysis to examine assemblies for more than 200 different possible coding standards violations in the following areas: ConQat: ConQAT is a toolkit for rapid development and execution of software quality analysis. It offers the base functionality for detecting clones in Matlab/Simulink models. Features  Integrated visualization of diverse quality features for software systems  Aggregation of quality metrics for quick overview of quality status  Flexible formation of project-specific quality dashboards  Support for numerous programming languages (e.g. C#, C++, Java, ABAP, ADA)  Integration of third-party analysis tools (e.g.Find bugs,PMD,FxCop)
• 3.
  Integrated Intelligent Research(IIR) International Journal of Business Intelligents Volume: 05 Issue: 01 June 2016 Page No.38-40 ISSN: 2278-2400 40 Code Smell Support SNO Smell Checkstyle DECOR infusion iPlasma JDeodorant PMD Stench Blossom 1 Brain Class   2 Brain Method   3 Data Class    4 Data Clumps   5 Dead Code  6 Duplicated Code     7 Extensive Coupling   8 God Class     9 Feature Envy     10 Instanceof  11 Intensive Coupling   12 Long Parameter List    13 Large Class     14 Long Method      15 Message Chains   16 Refused Parent bequest    17 Shotgun Surgery   18 Speculative Generality  19 Tradition Breaker    20 Typecast  21 Switch Statements   Total 4 9 12 11 4 5 8 Additional tools: Other tools or methods for code smell detection have been proposed. These are: FxCop for .NET, Analyst for Java (commercial), CodeNose(no longer available), JCosmo(for Linux), CloneDigger and ConQat (for clone detection). IV. SUCCESS FACTORS Restraint – The Tools should not overwhelm a programmer with the smells that it detects. Relationally – When presenting details about code smells, the tool should show the relationships between affected program elements. Partiality – The tools should emphasize smells that are difficult to see without tool support. Non – distracting – The tools should not distract the programmer. Estimability – The tools should help to estimate the extent of a smell in the code. Unobtrusiveness - The tool should not block the programmer from the other work while it analyzes or finds smells. Context sensitivity - The tool should tell first and foremost about smells related to the code the programmer is working on. Lucidity - In addition to finding smells, the tool should tell the programmer why particular smells exist. V. CONCLUSION Modern smell detection tools are very sophisticated and thus broadly used. However there are still some features and qualities missing. The smell detection tools have difficulties to show the relationships between affected program elements of a smell because they may be widespread. Another drawback is that most of the smell detection tools do not provide a continuous code analysis and need to be run manually. REFERENCES [1] Tae-Woong Kim and Tae-Gong Kim, “Specification and Automated Detection of Code Smells using OCL”, International Journal of Software Engineering and Its Applications, July 2013. [2] Fowler, M. and K. Beck, Refactoring: improving the design of existing code. 1999: Addison-Wesley Professional. [3] E. Mealy and P.Stropper, Evaluating Software Refactoring Tool Support, Proc.Australian Eng., April 2006 [4] T.Mens and T.Touwe, ―A Survey of Software Refactoring, IEEE Trans. Software Eng., vol. 30, no. 2, pp. 126-139, Feb. 2004 [5] Ancesca Arcelli Fontana, Automatic detection of bad smells in code, Journal of Object Technolog, 2011 [6] Black, Andrew; Murphy-Hill, Emerson: An Interactive Ambient Visualization for Code Smells. (2009) [7] Sebastian Hunkeler, Success Factors for Code Smell Detection Tools.