ࣾஂ๏ਓ ిࢠ৘ใ௨৴ֶձ
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS৴ֶٕใTECHNICAL REPORT OF IEICE.

ϓϨϑΝΫλϦϯάͷͨΊͷෆ٢ͳष͍ͷ‫ݕ‬ग़݁Ռͷ༏ઌॱҐ෇͚ηʔϦϜɹφολ΢οτ†

ྛ

৾ฏ†

ࠤഢ

‫†࢘ݩ‬

† ౦‫ۀ޻ژ‬େֶ େֶӃ৘ใཧ޻ֶ‫ڀݚ‬Պ ‫ֶ޻ࢉܭ‬ઐ߈
˟ 152–8552 ౦‫౎ژ‬໨ࠇ۠େԬࢁ 2–12–1–W8–83
E-mail: †{natthawute,hayashi,saeki}@se.cs.titech.ac.jp͋Β·͠ ϓϨϑΝΫλϦϯάͷద༻ՕॴΛಛఆ͢ΔͨΊɼιʔείʔυதͷෆ٢ͳष͍ͷ‫ݕ‬ग़‫͕ث‬ఏҊ͞Ε͍ͯΔɽ
͔͠͠ɼ‫ط‬ଘͷෆ٢ͳष͍‫ݕ‬ग़‫ث‬͸ɼ։ൃऀͷ‫ࡏݱ‬ͷ։ൃίϯςΩετΛߟྀͤͣɼؔ࿈͢Δष͍ͱؔ࿈͠ͳ͍ष͍
Λࠞࡏͤͯ͞ग़ྗ͢ΔͨΊɼಛఆͷίϯςΩετʹै͍ͬͯΔ։ൃऀʹ͸ద͞ͳ͍ɽͦͷ݁Ռɼ։ൃऀ͸ద͢Δष͍
Λಛఆ͢ΔͨΊͷ࣌ؒΛඞཁͱ͢Δͱ͍͏՝୊͕͋ΔɽຊߘͰ͸ɼෆ٢ͳष͍Λ։ൃऀͷ࣋ͭίϯςΩετʹै͍༏ઌॱҐ෇͚͢Δख๏ΛఏҊ͢Δɽզʑ͸ɼΠγϡʔ؅ཧγεςϜʹొ࿥͞Εͨɼ࣍ͷϦϦʔε·Ͱʹղܾ͢΂͖ΠγϡʔͷҰཡΛ։ൃͷίϯςΩετͱ‫͢ͳݟ‬ɽఏҊख๏Ͱ͸ɼΠγϡʔͷઆ໌จʹରͯ͠‫ػ‬ೳ૞ࡧख๏Λద༻ͯ͠ಘ
ͨ݁ՌͷϞδϡʔϧҰཡΛ༻͍ͯɼίϯςΩετʹؔ࿈෇͘ष͍Λಛఆ͢ΔɽίϯςΩετʹؔ࿈෇͘౓߹͍ʹΑΔ
༏ઌॱҐʹ‫͖ͮج‬ɼෆ٢ͳष͍‫ݕ‬ग़‫ث‬ͷग़ྗΛฒ΂ସ͑ͯग़ྗ͢ΔɽຊߘͰ͸ɼΦʔϓϯιʔεϓϩδΣΫτΛ༻͍ͯߦͬͨఏҊख๏ͷ༧උධՁʹ͍ͭͯ΋ड़΂ΔɽΩʔϫʔυϦϑΝΫλϦϯά, ‫ػ‬ೳ૞ࡧ, ෆ٢ͳष͍

Toward Prioritizing Code Smell Detection Results for Prefactoring
Natthawute SAE-LIM† , Shinpei HAYASHI† , and Motoshi SAEKI†† Department of Computer Science, Graduate School of Information Science and Engineering,Tokyo Institute of Technology
2–12–1–W8–83, Ookayama, Meguro-Ku, Tokyo, 152–8552 Japan
E-mail: †{natthawute,hayashi,saeki}@se.cs.titech.ac.jp
Abstract In order to find the opportunities for applying prefactoring, several techniques for detecting bad smells
in source code have been proposed. However, existing smell detectors are often not suitable for developers who
have a specific context because these detectors do not consider their current context and output the results that are
mixed with both smells that are and are not related to such context. Consequently, the developers have to spend aconsiderable amount of time identifying relevant smells. In this paper, we propose a technique to prioritize bad code
smells by using developers’ context, i.e., a list of issues in an issue tracking system that needs to be implemented
before next release. We applied feature location technique to the list of issues and used the results to specify whichsmells are associated with the context. Thus, our approach can provide the developers with a list of prioritizedbad code smells that is related to their current context. Several preliminary evaluations using open source projectindicated the eﬀectiveness of our technique.
Key words Refactoring, feature location, bad code smells
are summarized as a smell catalog with their names [1]ʙ[3].

1. Introduction

Code smells are often introduced when implementing new

Refactoring is a technique for improving the structure of
the software without changing its functionality [1].

features or by developers with high workloads [4]. In orderCodeto suggest refactoring opportunities to developers, various

fragment that indicates problems and should be refactored is

types of code smell detectors have been proposed by detect-called design flaw or code smell. Many types of code smells

ing these code smells automatically [5].
—1—According to the work by Meng et al. [6], developers do
not typically refactor their code unless they have to change

Changedescriptions

the code for fixing some bugs or introducing new features.

FL result:
List of modules

Featurelocation

However, existing code smell detectors generate a list of code
smells without considering such developers’ current context.
Source code

Most of the existing code smell detectors analyze the specified source code and present the detected smells ordered by

Code smell
detection

the attribute that is not related to the context of the developers such as module or severity to the developers. Such!!
!

list of smells is inappropriate when the user developers have!
!
!

Scoring

specific context such as the features that are planned to be

Code smells

implemented because both smells that are and are not re-

Figure 1: Overview of the proposed technique.

Output: prioritized smells

lated to the developers’ context are mixed and scattered allover the list of smells. As a consequence, the developers
have to spend a considerable amount of time specifying rel-

Section 3 discusses our preliminary evaluation. Section 4 describes related works. Finally, section 5 concludes this paper.

evant smells that fit their context since fixing such smells
may contribute to support their future implementation, i.e.,
improving the understandability or extendibility of the program. Such activity is time-consuming, in analogy with thatstatic analysis tools are not used well by developers due tothe large number of the detected warnings [7].
In this paper, we propose a technique to prioritize code
smells from code smell detectors by considering developers’
current context. This technique focuses on supporting the
prefactoring phase [1]. In the prefactoring phase, developers
improving source code’s extendibility and understandability
by refactoring their source code before implementing a feature to facilitate their implementation. In the proposed technique, we regard the change descriptions in an issue tracking
system that are going to be implemented by a particular
milestone as the developers’ context. Such changes are going to be implemented by modifying or extending existing
modules in the source code. These existing modules canbe located by using feature location technique [8], [9]. We
consider such modules as relevant modules because they arelikely to be the location for implementing the new feature in
the change description. As a result, code smells that appear
in relevant modules should have higher priority so that thedevelopers could easily distinguish them from irrelevant code
smells. Thus, with supporting from our technique, developers can obtain a prioritized list of code smells based on therelevance to their context.
We have preliminary evaluated our technique with several
open source projects, and the results indicate the potentialof the eﬀectiveness of our technique.
The main contribution of this paper is to show that the relevance between developers’ context and code smells can be auseful criterion for prioritizing code smells for prefactoring.
The rest of this paper is organized as follows. First, the next

2. Proposed TechniqueIn this paper, we focus on supporting an issue-driven software development project adopting an issue tracking systemsuch as SourceForge or Bugzilla to manage their lists of issues. Assuming that such projects have a list of issues thatneed to be implemented before a particular milestone, i.e.,releasing major or minor versions. Such list of issues is usefulto estimate developers’ context, and we regard the modules
that are likely to be modified as our estimation.
We propose a technique for prioritizing code smell detection results from existing code smell detectors by considering
the list of issues in the issue tracking system that developers
need to solve. Figure 1 shows an overview of our technique.
Each gray node represents a subprocess of our technique.
The input of the process is a list of issues’ change descriptions obtaining from the issue tracking system and the sourcecode of the targeted project. The output is the prioritizedlist of code smells based on the relevance to the developers’context. Our approach first uses the feature location technique to obtain the list of modules that are likely to be thetargeted modules of each change description. Next, we generate a list of code smells by applying an existing code smell
detector with the source code of the focused project. Then,for each code smell in the list, we calculate the score based on
the relevance of the prior result from feature location technique. Finally, we output the prioritized list of code smells
ordered by the score value mentioned above.
In our approach, we use the existing feature location andcode smell detection techniques. The next subsections describe the explanation of these techniques and how we applythem.
2. 1 Using Feature Location Technique
Many types of feature location techniques have been pur-section explains our approach and its automated toolchain.
—2—

Table 1: Example portion of code smell detector results
Type

EntitySAP Breakers org/gjt/sp/jedit

Granularity Severity
Subsystem

6

Bloborg.gjt.sp.jedit.Buﬀer Class

7

Feature Envy

buildDOM() : void

10

Methodposed with diﬀerent kinds of input and output [9].

Our

approach uses the one that takes a change description dand source code C as inputs and provides a set of methods
M = {. . . , m, . . . } with their probability as outputs. The

reason that we chose this type of feature location techniqueis that we focus on supporting the issue-based software development project which the developers tend to implement
features or fix bugs by following the change description in
an issue tracking system. In this situation, we assume that

Figure 2: TraceLab configuration.

such change description describes the new behavior of existing feature, i.e., fixing bugs or improving functionalities.
These existing features can be located by feature location
technique. Therefore, the located modules of these features
can be the candidates to be modified in order to achieve thechange. Consequently, applying the prefactoring techniqueto these modules is likely to support the developers’ implementation, i.e., improving understandability or extendibilityof the source code. Thus, this type of feature location technique suits our needs.

the weighted summation of the number of the modules in
the result from feature location technique that match eachsmells’ module. The score of each s ∈ S can be defined as⎧n!
! ⎨w(m), if match(m, entity)score(s) =⎩0,otherwise
i=1 m∈Mi

where function match(m, entity) is true when module mequals to or belongs to entity of each smell, and w(m) is

In this paper, we input a set of change description D =the weight of each module which can be the parameter of{d1 , . . . , dn } and source code C to the feature location tech-

our technique. If we treat every module equally, w(m) isnique and obtain a series of sets of methods {M1 , . . . , Mn }.

equal to one. However, we can utilize the probability of each

2. 2 Using Code Smell Detection

module from feature location technique result as a weight ofCode smell detection is a technique that generates a list ofeach module. In this case, w(m) becomes the probability ofcode smells from targeted source code. One example of theeach module. Nevertheless, in this paper, we focus on treat-approaches is to detect them based on particular metric val-ing every module equally. The reason will be discussed inues, e.g., lines of code (LOC). The input is the source code

Section 3.

that we want to analyze. The output is the list of smells.
Each smell consists of ⟨type, entity, granularity, severity⟩,

2. 4 Automation
We have implemented an automated tool for the proposed

where type is the type of the detected smell, entity is thetechnique. The chain is designed to connect with an exist-

module having the detected smell, granularity is the level ofing feature location tool. When executed, our tools trigger acode smell consisting of subsystem, class, and method, andcode smell detector to generate a list of smells and calculate

severity is an integer value for representing the strength of

the score of each smells based on the relevance of the result

the smell. Table 1 shows the example of code smell result

from feature location technique.

from the code smell detector. For example, the second row

For the feature location technique, we use the vector spaceshows the Bob smell in org.gjt.sp.jedit.Buffer class withmodel feature location technique [9] in a TraceLab-based so-severity 7. Note that we omitted the package and class namelution [10] proposed by Dit et al. because vector space modelof the method level smell.

is the foundation feature location technique that takes a text

In this approach, we apply the code smell detector andobtain the list of smells S.
2. 3 Scoring

document such as a change description as a query and find arelevant code based on statistical methods. Figure 2 shows
our configuration in TraceLab.

To indicate the priority of each smell, we define the score

For smell detection, we use inFusion v1.9.0 [11] because 1)

attribute. The value of the score attribute is calculated byinFusion is capable of exporting the results as a file, 2) it
has a command-line interface and 3) it can detect 24 types—3—

occur in the modules that were modified by developers dur-Table 2: Data sets information

ing two releases according to the data in feature location

Project

Version Size (LOC) # Issues # Smells

jEdit

4.2–4.3

176,098150387

bechmark because these code smells are relevant to the de-

ArgoUML 0.22–0.24

272,59091404

velopers’ context as we discussed in the previous section. As
for jEdit, we prepared the oracle by first applying the sourceof code smells such as Blob Class, Feature Envy, These characteristics suits our approach.
2. 5 Limitation
In our approach, the result is mostly aﬀected by the accuracy of feature location technique. That is to say, if we
use other types of feature location technique, the result may
diﬀer.

3. Preliminary Evaluation
We have conducted a preliminary evaluation to verify
whether our approach has the potential of eﬀectiveness withthe following evaluation questions:
EQ 1: Are relevant code smells placed in the higher rankof the list with our technique?
The aim of our approach is to put the relevant code smellsin the higher rank of the list for supporting the developers
specifying relevant smell. Thus, we confirm it by conducting
an experiment and analyzing the result.
EQ 2: Does our technique applicable to any entity type?
Since there are three types of entity generated by code
smell detector: subsystem, class, and method. We applied
our technique separately to each entity type and observed
the result.
EQ 3: Which weighting scheme provide a better result:treating every smell equally or using the probability value
from feature location result?

code at version 4.2 to the code smell detector and obtained
the result. Next, we prepared the gold set methods, themethods that were actually modified in order to solve eachextractable issue in jEdit’s issue tracking system by feature
location benchmark during version 4.2 and 4.3. Finally, weintersected these two sets together so that we can obtain alist of smells that is actually related to the developers’ context. We applied the same process to ArgoUML version 0.22
and 0.24.
As for the baseline of our evaluation, we used the original
result from inFusion v1.9.0 [11] sorted by the severity of eachsmell.
3. 2 Data Analysis
For evaluating the result of our approach, we use average
precision [12] as a criterion because it is considered a reasonable metric for evaluating the quality of ranking documents.
The relevant documents in the higher rank more contributeto the average precision than the relevant documents in thelower rank. Therefore, since the aim of our technique is torearrange the result from a code smell detector and put therelevant code smells in the higher rank, the average precision of the result from our technique should be higher thanthe baseline of our evaluation, the original result from code
smell detector. The following formula can calculate average
precision.
AverageP recision =As mentioned in Section 2, when calculating the scorevalue, we can either treat each module equally or use theprobability value from feature location result. We did anexperiment to see which is the better scheme.
3. 1 Data Collection
In this evaluation, jEditʢ*1ʣ and ArgoUMLʢ*2ʣ, active open
source projects, were our subjects because their data are
available through feature location benchmark [9] and we canobtain the gold set methods, the methods that were modified
by developers, which were associated with a particular issue
in the issue tracking system. Table 2 shows the informationof our data sets including the size of the source code of theearlier version, the number of issues that we used in between
two versions, and the number of smells detected by inFusion
v1.9.0 [11].
We first defined the oracle as a set of code smells that%r P @rR

where r is the rank of each relevant document, R is the total
number of relevant documents, and P @r is the precision of
the top-r retrieved documents. In this context, the relevant
document is the code smell that matches the items in theoracle, and the retrieved document is the code smell in the
result from the code smell detector.
We calculated the average precision of the baseline and theresult from our tools ordered by the score of each smell forboth jEdit and ArgoUML.
3. 3 EQ 1
As we can see from Figure 3, the average precision of theresult from our technique is significantly higher than the average precision of the baseline. This means that after prioritizing the list of smells by our technique, smells that are
related to the developers’ context are on the higher rank of
the list. As a result, the developers can directly focus on theʢ*1ʣɿhttp://www.jedit.org/

top rank smells without specifying which smell is or is notʢ*2ʣɿhttp://argouml.tigris.org/

related to their context.
—4—

nique. However, in ArgoUML case, only the average preci-

1

sion value of class and subsystem entity type is increased,
0.78

Average precision

0.8

not the method entity type. We investigated the result and

0.75

0.69 0.71

found that there are many smells that have zero score, butthey are matched with the items in the oracle. This means

0.6

that our approach predicted that these smells are not related
0.4

to the developers’ context while they actually are. One of

0.32

0.29

the reasons that might be the cause of this situation is theaccuracy of feature location technique. Since our technique

0.2

relies solely on the result of feature location technique, theaccuracy of feature location technique can also aﬀect the ac-

0
ArgoUMLjEdit
Baseline

Weight equallycuracy of our technique. That is to say, the feature location
technique may have failed to locate the correct module thatUse Probability

Figure 3: Comparison of the average precision value between

is the targeted of a change description. Consequently, ourresults of baseline and our approach.

method incorrectly predicted that this smell is not related tothe developers’ context and put it in the lower rank of the

We analyzed the result by considering the 1st rank in
the result from our technique. That is the Cyclic Dependency smell of package org.argouml.uml. This smell was
ranked 123rd in the baseline.

However, by applying ourtechnique, this smell becomes the 1st rank of the list withthe highest score. This is because this smell is related withmany issues that need to be solved by the developers. We
confirmed it by investigating the actual changes that weremade during revision 0.22–0.24. We found that out of 91 issues, 65 issues were implemented in org.argouml.uml package which contains this CyclicDependency smell.

There-

fore, if the developers realized the importance of this smell
and fixed it, it might be able to facilitate their implementation, i.e., improving the understandability or extendibility of source code for 65 issues. On the contrary, the 1st
rank in the baseline that is the SAPBreaker smell of packageorg.argouml.cognitive.checklist is ranked 61st in the result from our technique. This is also because this smell is related with only a few issues in the issue tracking system. We
also investigated the actual change and found that there is no
issue implemented in org.argouml.cognitive.checklist
package. Thus, if the developers picked the 1st smell in theoriginal result from code smell detector and fixed it, it might
not support their implementation for any issue at all.
This evidence indicates that a list of smells ordered by therelevance to developers’ context has a potential be able tosupport developers’ implementation more than the originalorder such as severity.
3. 4 EQ 2
Figures 4a and 4b shows the average precision of method,class and subsystem entity types of jEdit and ArgoUML
projects respectively. In case of jEdit project, all of the average precision for each entity type is higher with our tech-list. The reason that this is not the case for subsystem andclass level smells is that when we calculate the score value ofeach smell, the module m from feature location result must
equal to or belongs to entity of each smell s. Therefore, thecoarse-grained level code smells such as subsystem or classlevel code smells tend to satisfy the criteria more than thefine-grained level code smells like method level code smells.
This indicates that our technique is more appropriate withthe coarse-grained level code smells.
3. 5 EQ 3
Figure 3 shows the result of two diﬀerent weighting
schemes displaying in black and grey.

We can see that,for jEdit, the average precision when we treat each module
equally is slightly higher than when we use the probability
value as a weight. However, in case of ArgoUML, the average precision when we treat each module equally is slightly
lower than when we use the probability value as a weight.
Therefore, we can not determine whether which weighting
scheme provide a better result.
Since there is no significant diﬀerence between the twoweighting schemes, we focus on the method of weighting every smells equally because of the computational cost andsimplicity of the approach. However, it is possible to apply
other factors to the weighting scheme such as the importance of an issue, the severity of each code smell or the eﬀort
needed for solving each code smell. This remains our futurework.

4. Related Work
Some existing techniques also use the context of developers to detect code smells [13], [14], but can be regarded as
supporting the postfactoring phase because such techniques
detect code smells during the source code editing process ofdevelopers.
—5—

1

0.99

1

0.95

0.89
0.8

0.8
0.64

0.6

0.61

0.4

0.2

0.15

Average precision

Average precision

0.7

0

0.54

0.4

0.4

0.2

0.11

0.58

0.6

0.19

0
MethodBaselineClass

Subsystem

MethodResult from our techniqueBaseline(a) jEditClass

Subsystem

Result from our technique(b) ArgoUML

Figure 4: Comparision of the average precision value between result of baseline and our approach.

Moreover, since code smell detector tends to generate a

References

huge number of smells, many techniques have been proposed[1] M. Fowler, Refactoring: Improving the Design of Existing
Code, Addison-Wesley”, 1999.
[2] William C. Wake, Refactoring Workbook, Addison-Wesley,
2003.
[3] M. Lanza and R. Marinescu, Object-Oriented Metrics inPractice, Springer, 2006.
[4] M. Tufano, F. Palomba, G. Bavota, and R. Oliveto, “Whenand why your code starts to smell bad,” Proc. ICSE,
pp.404–414, 2015.
[5] M. Zhang, T. Hall, and N. Baddoo, “Code bad smells: A
review of current knowledge,” Journal of Software Maintenance and Evolution, vol.23, no.3, pp.179–202, 2011.
[6] N. Meng, L. Hua, M. Kim, and Kathryn S. McKinley, “Doesautomated refactoring obviate systematic editing?,” Proc.
ICSE, pp.393–402, 2015.
[7] B. Johnson, Y. Song, E. R. Murphy-Hill, and Robert W.
Bowdidge, “Why don’t software developers use static analysis tools to find bugs?,” Proc. ICSE, pp.672–681, 2013.
[8] V. Rajlich, Software Engineering: The Current Practice,
Chapman and Hall/CRC, 2011.
[9] B. Dit, M. Revelle, M. Gethers, and D. Poshyvanyk, “Feature location in source code: A taxonomy and survey,” Journal of Software: Evolution and Process, vol.25, no.1, pp.53–
95, 2013.
[10] Center of Excellence for Software Traceability, “TraceLab,”
http://www.coest.org/index.php/tracelab/.
[11] Intooitus, “inFusion,” http://www.intooitus.com/products/
infusion.
[12] E. Zhang and Y. Zhang, “Average precision,” Encyclopediaof Database Systems, pp.192–193, Springer, 2009.
[13] S. Hayashi, M. Saeki, and M. Kurihara, “Supporting refactoring activities using histories of program modification,”
IEICE Transactions on Information and Systems, vol.E89D, no.4, pp.1403–1412, 2006.
[14] H. Liu, X. Guo, and W. Shao, “Monitor-based instant software refactoring,” IEEE Transactions on Software Engineering, vol.39, no.8, pp.1112–1126, 2013.
[15] T. Komatsuda, S. Hayashi, and M. Saeki, “Supporting prefactoring using feature location results,” IEICE Technical
Report, vol.114, no.127, pp.109–114, 2014.
[16] F.A. Fontana, V. Ferme, and M. Zanoni, “Filtering code
smells detection results,” Proc. ICSE, pp.803–804, 2015.

to reduce the number of code smell detection results. Komatsuda et al. [15] proposed a technique to detect code smellthat are relevant to developers’ context by inserting dummycode fragment. Fontana et al. [16] proposed a technique toreduce the number of code smell detection results by applying strong and weak filters. The novel point of our approachcompared to them is that our approach can be applied to
any kind of smell. We prioritize every smell in the detection
result based on the relevance to the developers’ context.

5. Conclusion
In this paper, we proposed a technique for prioritizing code
smell detection results by considering developers’ current
context. The result of our technique is the list of prioritizedsmells based on the relevance to the developers’ context. The
more relevant with the developers’ context, the higher rankthat smell is placed on the list. Therefore, our approach can
assist the developers prioritizing code smells for prefactoring
phase. Our technique can be used for planning how to prefactor the source code before implementing sets of issue in anissue tracking system. Our preliminary evaluation indicatesthat our technique is potentially useful.
Our future work includes conducting case studies to confirm that relevant code smells, as defined in this context,
are useful to developers. Also, we should consider other factors that might aﬀect developers’ decision whether to fix thesmells, e.g., the severity of smells, the eﬀort needed to fix thesmells or the importance of the issues. Also, More projects
are needed to evaluate our technique.
Acknowledgement. This work was partly supported by
JSPS Grants-in-Aid for Scientific Research (#15K15970).

—6—