Detecting code smells in educational software:

an in-depth study by David Jnsson dt05dj3 Mars 05, 2013

Abstract Detection of code smells is an important step to take during a refaktoring process. It helps to identify areas where the code might be lacking either in architectual design or on the verge of increased complexity. Detecting code smells can be a repetitive and mundane task that invites the developer to overlook faulty code. Therefore an automated tool would be to prefer when detecting code smells. JDeodorant and PMD was chosen due to ease of access to the ducational project during the course EDA260 at the Faculty of Engineering (LTH) at Lund University and will be evaluated with regards to their usefulness and useability during said project.

1. Introduction
During a software development project the developers will eventually end up in a situation where they will need to refactor their code. During the refactoring process there is a step where you aim to detect code smells. This process is very repetitive and time consuming. The project relevant to this study is developed by students who have varying experience of both developing code and refactoring code. This will make the result of finding code smells very unpredictable on top of still being repetitive and time consuming for the developers. This advocates the use of a automated tool to detect code smells that will reduce the strain on the developers and also increase the quality of the code. This study will evaluate the usefulness of automated code smells detection in an ducational software development project. The evaluation will be done by letting eight students use the tools selected for evaluation during their project. To assess the strength and weaknesses of the tools a interview with the students will be conducted at the end of the project. The intwerview will be structured and lead by a senior student who is also their coach during the project. The interview will have questions focused on getting feedback regarding mainly the usefulness, useability and ducational value of the tools. The feedback gained from the interview will later be used as a basis for concluding if either of the tools should be used in similar projects.

2. Theory
This section includes theoretical background to code smells, refactoring and the ducational project that this study is related to. The theory behind code smells will explain what makes them hard and repetitive to detect and also which problems can arise if they are not handled. How to fix code smells will be discussed in the section about refactoring and the context for the study will be

handled in the study context section. Finally a section with theory around automated tools will explain the basics of code smell detection tools. 2.1 Code Smells Code smells are bad code patterns that stems from bad programming practices[3]. They manifest in numerous forms. Some are a bit easier and mechanical to detect such as: Duplicated code is when code functionality is repeated in the source code. It is most commonly found in a class where several methods have similar functionallity which lures the developer to repeat the same base code in each of the methods. The problem with duplicated code arise when you need to maintain it. If you need to update a method that has been duplicated you will need to change it in every instance it is implemented which is more time consuming than changing it in only one place and also involves the risk of missing one of the numerous implementations. Large classes are classes where the developer have gathered too much functionality so that the class has too many responsibilities. This results in confusion regarding how to use the class, when to use the class and what result can be expected when using the class. Large classes also pose a problem with maintenance since it will be hard to know the purpose of the class. Long methods are similar to large classes in the way of confusing other developers regarding it's use and expected result. The problems with maintenance are also shared between these smells.

While these code smells are a bit easier to detect from a knowledge standpoint it is still hard to find all of them due to the repetitiveness of going through code to find them[1]. Each smell has their own signatures, often more than one, and thus are detected by different means. Duplicated code can for instance be either straight up identical code put in different methods or code which has the same functionality while being named differently[4]. This makes the detection process very time consuming as the code complexity and size increase which makes these code smells wel suited to be detected by automated tools.

2.2 Refactoring
Refactoring code is the process of reorganizing code with the intent of simplifying both design and structure while not changing the functionality of the code[1]. During the refactoring process one of the steps is to detect code smells and remove them. Removing code smells is done differently for each indivudual smell. Duplicated code is removed by creating a single method containing the shared parts of all the duplicates. This method is then called in each place where a duplication was used and that's where the unique parts are added. Large classes are fixed by deciding on a purpose for the large class and then only including the functionality that fulfills this purpose. Everything else in the class is moved either to other existing classes or into newly created classes. Long methods are handled similarly to large classes by dividing it into two or several methods that together has the same functionality. Where each divided method is placed depends on where it's functionality is most relevant.

Another important aspect of refactoring is to increase the readability[2] of the code. This serves to help developers understand the code easier and if need be maintain or further develop the existing

code. Removing code smells should be done with this in mind so that the code will not be harder to read and understand after the smells are gone. 2.3 Study context The development team is comprised of eight students from the Department of Computer Science at LTH in the course EDA260[5]. The degree of their knowledge and experience in developing software varies a lot although there are requirements to have passed certain basic programming, code design and code architecture courses. Including ways of code smell detection and methods for removing them. During the project the team will be tasked with developing software for a mock client and are expected to learn the practices of eXtreme Programming gradually. These practices are a bit modified to fit the peoject acording to the paper "Software Configuration Management Practices for eXtreme Programming Teams"[6]. They learn them by shifting focus between the practices while maintaining the knowledge already learned. It is first during week three that the team will focus on code quality and refactoring. The team is reminded during a planing meeting before week three that refactoring is key to maintaining a high code quality as well as a relevant and flexible architecture. Two team members were assigned a spike to research each tool and write a short introduction to them for the other students. During and after week three the team was reminded to use the tools in combination with manual code analysis during refactoring to make sure that the tools didn't miss anything. Although code quality is only being the focus during week three it is neither neglected before or after week three. However as a coach it seemed more appropriate to introduce the code smell detection tools when the code quality was the weekly focus. This results in a rather short time frame for the team to get familiar with the tools but they will still get a good appreciation of how well the tool suits their and future teams needs for the project. 2.4 Automated tools There are many tools which focus on detecting code smells but no tool that can detect all of them. Most of the tools can detect basic code smells which are the ones that are easiest to define such as duplicated code and large class while others have a much broader amount of smells that they can detect. Some of the more popular tools have been compared thouroughly without any conclusion on which tool performed best in detecting code smells over all[4].

3. Tools
This section includes a description of which tools were evaluated. There is also descriptions of how they are accessed and used. Due to some tools being commercial and thus not relevant for this project and the limited time frame this study will only include two tools. The tools that were considered but not chosen will be described and argued for why they were not included. The last section will motivate how the tools were chosen.

3.1 JDeodorant JDeodorant is a very targeted tool that focuses on finding four specific bad smells namely Large Class (called God Class), Long Method, Duplicated Code and Feature Envy. While not only detecting bad smells it is one of the few tools that also gives the user an advice on refactoring

transformations[4]. This tool is a simple Eclipse plugin available via the eclipse marketplace for free. How to install the plugin is described at the developers webpage[7]. It's very easy to use and due to it's small amount of smells to detect doesn't need much work setting up. The plugin adds a new menu item to the eclipse menubar which is used to open the four different views for searching for thier respective code smell. The simple design and installation process as well as being free makes this tool very well suited for this study. However it would be good to be able to find some more code smells.

3.2 PMD PMD is in comparsion to JDeodorant a much more complex tool even though it only includes searches for five code smells rather than 4. It is also available as an eclipse plugin installed acording to their webpage[8]. PMD can detect code smells consistent with Large Class, Long Method, Long Parameter List, Duplicated Code and Dead Code such as empty try catch. The complexity of using PMD stems from the high number of configuration choices available. There are a few hundred rules that can be mixed together in any number of combinations to get the desired search result. Although a bit more complex than JDeodorant it is also free and easily accessed with the advantage of being able to detect more code smells. The high amount of configuration also ads the advantage to pinpoint what kind of smells you want to find in an easier way than the other alternatives.

3.3 CodeNose CodeNose was developed in 2005 as a prototype for automated code smell detection due to the lack of tools at that time. It is implemented as a plug-in for eclipse which detects and presents code smells similar to how compilation errors and warnings are displayed[2]. The tool can detect a high number of code smells ranging from the easier duplicated code and large classes to the more complex code smells such as refused requests and feature envy which are described further by the auther of CodeNose[2]. While this tools seemed very promising for this study the miantenance and availability of the tool has been discontinued. It has been aquired by some people by contacting the developer but due to the limited amount of time for this study there was no time to contact the developer and establish a dialog about using the tool in this project. 3.4 inFusion inFusion is a very versatile tool that can detect up to 20 code smells. It has support for the easier code smells, complex code smells and can also detect several design flaws such as bad class hierarchies[4]. inFusion is an evolution of iPlasma which operates as an integrated platform. Although inFusion can find many code smells and has a good way of showing the result of an alnalysis it is commercial and therefore not very suited for this study. 3.5 CodePro Analytix While not being a tool for exclusively for detection of code smells CodePro features some functionality for it. It is a free tool developed by the google development team as a eclipse plugin. It can detect duplicated code (called similar code) as well as bad naming habits and dependency issues[9].

For this study CodePro was not selected due to the low amount of code smells it can detect and having distractions from the main focus with the additional functionality not relevant to detecting code smells. 3.6 Choosing the tools For this study it was important to choose tools that were easily accessed by the team. They had to be free to use due to the nature of the project having a very limited budget. The limited time frame of the project and the small test group made me limit my choices to to a set of two tools instead of including several more. Having only two tools it was important that they were not too similar so that there could be a relevant comparision between them. CodeNose was excluded due to the discontinuation of availability. When considering these criteria I found that JDeodorant and PMD were the best choices. JDeodorant was simplistic in both design and usage while PMD was a bit more complex. Although not large there was also a difference in the number of code smells they could detect. I could have chosen CodePro instead of JDeodorant for the simplistic tool but the extra features that came with it seemed to take focus from the purpose of the study in a way JDeodorant did not.

4. Results
This section will report and evaluate the feedback from the team that used the tools chosen in this study. The feedback will be conducted in the form of a structured group interview including all the team members lead by a senior student coaching the development team. The first section will include which questions were asked in the interview and the purpose of each question. The feedback section includes the answers from the development team and the last section analyses these answers. 4.1 Interview The questions were devised to focus on three main attributes of the tools, usability, usefulness and educational value. The questions asked and their purpose were: 1. Did you encounter any problems with installtion of the tools? If so what and for which tool? This question was asked make sure the tools were easily accessed for the team and not troublesome to install. 2. Was it evident how to use the tools when using them for the first time? A tool that is intuitivly used correctly makes it much easier to understand and reduces the amount of errors made while using it. 3. Where there any problems configuring the tools to make them perform in a way suitable for your needs? Complicated configuration will make the tool frustrating to use and will lower the usability of it. 4. Do you estimate that the tools can find an ample amount of code smells? The purpose of the tools are to find code smells and this question will confirm if they are useful at this task. 5. Which tool found the most code smells? For the purpose of finding the most compatible tool this question will give some manor of comparing the tools.

6. Which tool had the best display of it's results? This question will derive if the tools can display their results in a proper manor for the students to see patterns in the code which are prone to include code smells. 7. Which tool gave the best sugestions for refaktoring? Giving accurate sugestions for refaktoring is important so that the students does not pick up bad refaktoring habits while using the tool. 8. On a scale from 1-5 how well did you think the tools are suited this project? A tool might be suitable for a project in theory but this question aims to confirm if it's useful in practice as well. 9. Which tool are you most likely to use in future projects? JDeodorant, PMD or none/other? This question will give an overall rating as to the students preferences for tools. If they are willing to use it in future projects the tool has an overall usefulness and is easy to use. 4.2 Feedback The feedback was accumulated by letting the development team discuss the questions and come to a common concensus about the answer. I took notes of both the answers and some observations from the discussions that occured. For the first question the team was unanimous about not having any problems at all installing the tools. This was partly due to the none complex installation process of the tools and also the guide made during the spike to get familiar with the tools. Even with a thourough guide available from spikes some team mebers still found it a bit hard to navigate the menu options for the tools. This resulted in a brief adjustment period before the team could use the tools correctly. In regards to question three the team felt that JDeodorant had too few options for configurations making it hard to specify which kind of code smells they wanted to detect. In contrast to this PMD had too many configuration options which made it too complex to get it right. This had the unfortunate result of the team completely neglecting to use PMD and instead favoring JDeodorant. As such the remaining questions will only include feedback regarding JDeodorant. The team felt that JDeodorant overall found a ample amount of code smells with a large amount of large class smells and a decent amount of duplicated code. Some long methods were found and they were generally content with how many code smells were detected. JDeodorant displays which section has code smells by olour coding them while also providing a list of each code smell found. This system appealed a lot to the students who found it easy to navigate and they got a good overview of the code sections with code smells. There were some mixed feelings about the refactoring sugestions made by JDeodorant. Some thought they were mostly good while others thought they were in general too radical and generalized. However all the team membes agreed that the average quality of sugestions were useful and if nothing else gave them an idea of how to manually refactor the code. The overall rating had varied results ranging from 2-4. The students that were most pleased argued that the tool saved them a lot of time while also giving them some additional insight in their code. The bad reviews were from students wanting more pinpointed code smell detection and in general more options to work with. The average result ended up at a 2.5 out of 5. For the question about which tool they would prfer to use in future projects they all answered that

they would use neither PMD nor JDeodorant but rahter CodePro. The argument was that although detecting few different code smells CodePro got the most repetitive once while also combining other features such as checking test coverage. It was more convinient to use one tool for all purposes instead of installing one tool for each purpose. 4.3 Analysis The answers in general were as I had expected them to be after observing the team as they worked with the project. The most suprising result was that they hadn't used PMD at all to evaluate their own code. At most they had given it a testrun but then come to the conclusion that it was too time consuming to configure the tool to suit their needs. It may seem a bit contradicting that they criticized JDeodorant for having too few options while condemning PMD to have too many but that stems from the range of options in JDeodorant being in the lower double digits while PMD are in the tripple digits. The teams feedback further suggests that JDeodorant fulfills it's purpose in spite of the drawbacks it has. It's biggest weakness being the narrowness of it's features while it's best strength is the way results are displayed alowing the user to make their own decision wether to use the automated refactoring or do it manually.

5. Conclusion
It is evident that PMD was not very well suited for use in the project part of the course EDA260 due to the complex and time consuming configurations that had to be made to use it properly. The feedback gathered during the interview tells us that a tool should not only be easy to use and fulfill it's purpose but also be very versatile. Even though CodePro couldn't find as many code smells as JDeodorant the students very much prefered CodePro due to it's many other features. Having one broad tool which helps in many areas seems to be more important than having one tool for each specific task. However for the specific task of detecting code smells and removing them JDeodorant is a tool with few drawbacks that finds the most relevant code smells and presents the user with suitable options for proceeding to fix them either automatically or manually.

6. References
[1] "Integrating 'Code smells' Detection with Refactoring Tool Support"- Kwankamol Nongpong, University of Wisconsin-Milwaukee 2012 [2] "Code Smell Detection in Eclipse" - Stefan Slinger, Delft University of Technology 2005 [3] "Automatic detection of bad smells in Java code" - Deepak Bhalla, ISBN: 1109030916, California State University 2009 [4] "Automatic detection of bad smells in code: An experimental assessment" Francesca Fontana, Pietro Braione, Marco Zanoni, University of Milano-Bicocca 2011 [5] "EDA260 course webpage" [6] "Software Configuration Management Practices for eXtreme Programming Teams" Ulf Asklund, Lars Bendix, Torbjrn Ekman, Lund Institute of Technology [7] "JDeodorant installation" - http://www.jdeodorant.com/ [8] "PMD installation" - http://pmd.sourceforge.net/eclipse/ [9] "CodePro User Guide" - https://developers.google.com/java-dev-tools/codepro/doc/