Fascinating Observation Monitor-based Clamant Code Smell Detection Using Python

Transcription

1 Fascinating Observation Monitor-based Clamant Code Smell Detection Using Python M.Sangeetha 1, Dr. P.Sengottuvelan 2 M. Sangeetha, Ph.D Research scholar, Department of computer science, Periyar University PG Extension Centre, Dharmapuri, INDIA Dr. P. Sengottuvelan, Associate Professor, Department of computer science, Periyar University PG Extension Centre, Dharmapuri INDIA Abstract Code Smell or Bad Smell, at the very most, is an pointer of badly for source code and is often analytical of deeper problems in software design. Code smells are symptoms of subconscious problems in design, which, in most common cases, condense the understandability of the system for present and future programmers, therefore representation the program unmaintainable. Identification of these code smells has been thought of as an unprompted art rather than an exact science, as there are very few empirical measures or methodologies for doing so. This paper implements Python which will follow a scientific approach to detect five of these 30 code smells. Python will give suggestions to refactor the code for all five of these smells. Further, the tool will provide an interactive process to refactor two of these cases; while for the rest, it will suggest an ideal refactoring technique that would need to be applied manually. Index Terms Code smell, tools support, Python, detection techniques, refactor. I. INTRODUCTION SOFTWARE bad smells are patterns of poor design and flaws that make software code more drifts and weaken. Bad smells does not prevent source code to show any input. There are no effects of output but code becomes too hard to modify and adapted new requirements [1]. Software Refactoring is to restructure the code in a series of small internal structure of objected oriented software that is to improve the software quality based on the terms of maintainability, extensibility and reusability without changing the external behavior of the software. The term Refactoring was first proposed by Opdyke after it became popular by the book written by fowler et.al that published in the year 1999.Refactoring was tracked by the re-structuring which was the extended history in the literature. [2]Kim et.al assessed the value of software refactoring within Microsoft and suggested that refactoring is visible. Software refactoring tools are significant to support. For this, researchers have proposed tools to provide software refactoring. Most predictable Integrated Development Environment (IDE) such as Eclipse, Microsoft Visual Studio and IntelliJ IDEA provide tools support to conduct refactoring. Developers have to identify the refactoring opportunities if not they can t apply refactoring tools. Researchers have précised a number of typical situations which may need refactoring which Fowler calls bad smells. Experts proposed various smells detection algorithms that to identify different kinds of code smells that may be automatic or semi automatic. Extant refactoring tools and smell detection tools are inactive and human driven. Murphy Hill et.al[3] programmers fail to invoke refactoring tools and smell detection tools which may result in delay of refactoring and results in higher cost of refactoring. The reason for that is that unaware of extant tools, don t know where to invoke the tools and when to detect and how to resolve code smells.. II. PROBLEM STATEMENT During the changes in the source code there might be an incidence of smell. Fowler calls as a Bad Smell which is the symbols of possible problem in the code that may require a refactoring. Inexperienced software felt difficult to resolve the bad smells even with the help of refactoring tools. The reason is that the developers don t know where to invoke the refactoring tools and how to choose 128 M.Sangeetha, Dr. P.Sengottuvelan

2 the refactoring tools for identifying various code smells. For this we proposed a framework to perform refactoring instantaneously. By this the developer may refactor the bad smells and resolves them promptly. III. SYSTEM ARCHITECTURE The framework is made up of a monitor, a set of smell detectors, set of refactoring tools, a smell view, and a feedback controller. In the following paragraphs, these components will be separately introduced. Fig 1 Instant Refactoring Framework using Python The monitor survey changes made on source code. Once the monitor realizes that such changes might introduce code smells, it invokes corresponding smell detection tools. Accordingly, the main task of the monitor is to evaluate changes directly, and then to decide when and which detection tools should be invoked. A prospective challenge that the framework might come across is that the framework might fatally affect IDE s performance. Smell detection tools are usually resource consuming. Therefore, IDE s might become indifferent if smell detection tools run repeatedly so as to account smells instantly. To minimize this impact, the monitor takes several measures to minimize the frequency of invocation of smell detection tools under the premise of timeliness. Consequently, the monitor unambiguously specifies the most recent changes, and invoked smell detection tools minimize their search scope according to such changes. A narrowed-down search scope significantly improves the efficiency of detection algorithms because the complexity of these algorithms is usually in direct proportion to the search scope. For some kinds of code smells, e.g., public field and data class, the search scopes of their detection algorithms are confined to newly modified files. However, this condition is not necessarily true for other smells. For example, to detect duplicate code caused by the most recent changes, detection tools have to search the entire source code. However, even in this case, incremental detection tools could be faster than traditional non incremental detectors. in C# language for Java. It detects seven of the code smells: Data Class, Message Chain, Primitive Obsession, Speculative Generality, Parallel Inheritance Hierarchy, Duplicate Code, and Comments. Bad smells detected by Python. Automated smell detection process involves the use of data structures, metric count and information generated from the parser. Python detects the following code smells. i. Data class ii. Message chain iii. Primitive obsession iv. Speculative generality v. Parallel inheritance hierarchy vi. Duplicated code vii. Comment There is a separate algorithm to detect each code smell. The notation of algorithm is used static analysis technique for code analysis. Considered any one of the following code smells the refactoring can be done by the programmer with the help of various refactoring tools. But the programmer needs to identify the refactoring methods to refactor the bad smells, the bad smell can be visualized by using the Python and it can be resolved with the help of refactoring methods. Python makes the programmer convenient for refactoring with the instant code smell detection. By Python the programmer can detect the twentykinds of bad smells which are Data Class, Large Class, Long Method, Switch Statements, Public Field, and Common Methods in Sibling Classes, Duplicate Code, and Long Parameter List, Feature Envy, God Class, Type Checking. These kinds of bad smells are detected and tools get evaluated and compared with the human driven refactoring. Python has implemented detection algorithms for Data Class, Large Class, Long Method, Switch 129 M.Sangeetha, Dr. P.Sengottuvelan

3 Statements, Public Field, and Common Methods in Sibling Classes, Duplicate Code, and Long Parameter List. Developers can locate corresponding source code by double clicking on items (smells) in the view. A double click also brings forward details on smells and corresponding refactoring suggestions. Fig 2. kinds of Smells and its Explanation Fig 3. Screen shots for code smell detection using Python 3. Time taken to add functionality in the code before and after refactoring. A. Recognize Smells Present in Each During this test, the Python was run across each of the project and the output was recorded (whether the project contains the unambiguous smell or not). later they were cross- checked by the graduate students to verify accuracy of the smell identified by the tool. Even other classes of the projects were skimmed through to identify other cases which the tool might have missed. B. Time Taken to realize Code Logic Before and After Refactoring For this test, four Python developers were chosen ranging from two to seven years of experience. The experience of the users ensured that they had sufficient background knowledge of Python to understand the logic. Three projects (named 1, 2, and 3) from the 28 of the above projects were selected having different difficulty level. The details of each of the three projects are shown in Table. Each of the projects was run across Python and individual smells were detected. The detected Data Class smell and Long Method smell were refactored by the tool and given to the developers in random order. For Example, if the 1 original (non-refactored) code was given first; next time any of the refactored projects or original projects was given. The users were asked to understand the logic of the code for which they were timed. The time taken by each of the users was noted and is enlisted in below Table I. IV. RESULT Python was tested against 28 projects taken from the graduate students. These selected students have experience of Python developers, so the difficulty of their code is considerable. Each project has an average of 15 classes. These test codes are their class assignments, hence have a good level of intricacy.. The feedbacks were used to manage the GUI. To test the usability, recital and the code optimization feature of Python, three different tests were conducted. 1. Identify smells present in each project. 2. Time taken to understand code logic before and after refactoring. Student1 Student2 Student3 1 Half Adder Circuit (Observer Observable Pattern) 2 A console application determine if entered number is Prime or Square or Sum of square or Biggest Prime number (Master Slave Pattern) 3 A GUI application, represents a rectangular shape which changes its size on user input Table M.Sangeetha, Dr. P.Sengottuvelan

4 The graphical representation of time taken to understand the logic of original and the refactored code by each user is shown below. Each graph represents the time taken for individual projects. he statistics above supports the fact that after refactoring; the logic of the code becomes easy to understand. However the user test results cannot be statistically used to validate the consequence of results due to small number of users. Student1 Origin al Refacto red TABLE. II Time taken in seconds Student 2 Origin al Refacto red Student 3 Origina Refacto l red User User User User Fig 4. 2 C. Taken to Understand Code Logic Before and After Refactoring This test was performed on two separate users, one of them the original writer (originator) of the code and the other an experienced Java developer. For this test, the users were asked to add functionality to the half-adder circuit project. The users were first given the original code and than refactored code one after another. The original code had Long Method smell which made it harder for the user to understand the code. In the refactored code, Long Method smell was removed by the tool. After each step, the users were asked to understand the code and add the functionality of full-adder circuit. The time taken by each of them was recorded, enlisted in below Table. Fig USER Fig Time taken in seconds Half-adder to Full-adder Original Refactored Originator Developer TABLE III A. Time Taken to add Functionality The graphical representation of time difference to add the functionality to the code in original and the refactored code taken by each user is shown in Graph. The statistics from this test supports that time taken to add functionality in the half- adder project is approximately half for the refactored code than the time taken for the original code. This even holds true for the originator of the code (who wrote the code) as well as for other developer. This shows that the refactored code is easy to preserve and modify than the code with smells and has nothing to do with who developed the code. However, the 131 M.Sangeetha, Dr. P.Sengottuvelan

5 consequence of the results cannot be trusted as the number of users is less. The research needs to be performed on a bigger set of users to trust the results. VI. FUTURE WORK Python detects code smells in Java systems only. Similar technique can also be deployed to detect the code smells in other object-oriented languages like C++, Ruby, Python, and C#. Furthermore, Python currently detects only five of the code smells, more research can be done to distinguish other code smells. Among these five smells the Long Method smell can be improved by having a better logical perceptive of the method. Moreover, if Python provides an interactive refactor advance for other code smells, it will become a powerful tool. Fig. 6. Time taken. V. CONCLUSION We propose a Clamant refactoring with Monitor framework which makes the developer to identify the changes of the source code that results in the bad smells and to resolve bad smells. We also evaluate the proposed framework, and the results suggest that this framework could drive inexperienced engineers to resolve more code smells (an increase of 140 percent) promptly (smell lifespan reduction of 92 percent). Python is a mostly challenging language to write code in and maintain. accordingly, Python programs contain code smells which indicate potential conception and maintenance problems. With the aim of supporting refactoring strategies to enhance maintainability, this paper describes how to detect code smells in Python programs using monitorbased framework. Pysmell can detect 285 code smell instances in total with the average precision of 97.7%. It reveals that Large Class and Large Method are most prevalent. Our experiment also implies Python programs may be suffering code smells further. REFERENCES [1] M.Flower with contributions by kent beck,john brant, William Opdyke and Don Roberts, Refactorings improving the design of existing code Indiana : Addison Wesley, [2] Roperia, N. JSmell : A Bad Smell detection tool for Java systems, Long Beach, CA, USA: ProQuest Dissertation & Theses, December, [3] E. Murphy-Hill, C. Parnin, and A.P. Black, How We Refactor, and How We Know It, IEEE Trans. Software Eng., vol. 38, no. 1, pp. 5-18, Jan./Feb [4] Peter Weibgerber and Stephan Diehl, Identifying refactorings from Source-Code changes in Proceedings of 21 st IEEE/ACM International Conference on Automated Software Engineering ASE 2006, Tokyo,Japan. [5] Carsten Gorgand Peter Weibgerber, Detecting and Visualizing refactorings from Software Archives, Proceedings of the 13 th International Workshop on program Comprehension (IWPC 05) /05 $20.00 IEEE. [6] Hui Liu, Xue Guo, and Weizhong Shao, Monitor- Based Instant Software Refactoring, IEEE Transactions on Software Engineering, vol.39,no.8,august M.Sangeetha, Dr. P.Sengottuvelan