2018 IEEE International Conference on Software Maintenance and Evolution
Towards Feature Envy Design Flaw Detection at
Block Level
Árpád Kiss and Petru Florin Mihancea
LOOSE Research Group
Politehnica University of Timişoara, Romania
Email: arpad.kiss29@gmail.com, petru.mihancea@cs.upt.ro
Abstract—Software is continuously evolving as bugs need to
be fixed and new features need to be added. Design flaws hinder
the simple evolution of software and thus, we have to detect and
correct them. Feature Envy is an object-oriented design issue that
can be detected at the level of methods using different state-of-
the-art approaches. Unfortunately, these are insufficient because
only a portion of a method may actually be affected by this flaw.
Thus, only that part needs to be treated using the corresponding
correction strategy, not the entire method. To address this issue,
we propose the detection of Feature Envy code smell at the level
of blocks of code. Initial evaluation suggests that our approach
is promising in spotting the envious areas within a method.
Keywords-feature envy, design flaw detection, refactoring
I. I NTRODUCTION
Nowadays a never-ending amount of code is written by
developers and gets deployed in various software products.
While it may function satisfactorily at that moment, require-
ment changes, new features and other kinds of enhancement
requests will definitely imply source code modifications in the
future. Unfortunately, when a software product is continuously
changed and/or extended through time, it inevitably grows in
complexity. Developers will start spending more and more
time on understanding their own or others’ source code in
order to modify it, adapt it and search it for bugs. An option to
reduce the ever growing complexity of code is to continuously
detect and eliminate emerging design flaws.
Fowler et al. [1] define 22 recurring bad smells (i.e., design
flaws) by the elimination of which one may increase the
maintainability of an object-oriented program. We focus on
the design problem known as Feature Envy, occurring when
a method is more interested in the data belonging to another
class rather than of its own. In short, the treatment of this
“disease” consists of moving the method to the envied class.
However, we have to first identify the problematic entities.
Different approaches are presented in the state-of-the-art
literature for the identification of the Feature Envy bad smell
e.g., [2], [3], [4], [5]. For instance, Lanza and Marinescu [2]
define specific object-oriented software metrics and use them
in combination, in the form of a detection strategy, for the
identification of envious methods.
However, all these approaches are insufficient because they
identify the flaw only at the method level. This is problematic,
because “sometimes only part of the method suffers from
envy” [1]. In these cases, only the envious part of the method
2576-3148/18/$31.00 ©2018 IEEE
DOI 10.1109/ICSME.2018.00064
should be extracted and moved to the envied class, not the
entire operation. Consequently, to simplify the maintainer
activity in identifying these sub-method fragments that need
to be refactored, a more fine-grained detection mechanism
is needed. Furthermore, this mechanism is also necessary if
a higher degree of automation of the entire detection and
correction process is desired.
The same limitation is also recognized by Lanza and
Marinescu [2]. Due to dependencies between the problematic
method and the class declaring it, the authors reiterate that “it
is very rare that we can move the whole method to the other
class”. Moreover, the authors explain that a method affected by
the Brain Method flaw may contain portions that are actually
affected by the Feature Envy problem. Thus, a fine-grained
detection mechanism of the latter bad smell at a sub-method
level, could also help a maintainer to spot more easily envious
parts “hidden” in complicated and large methods.
As a result, we propose the detection of Feature Envy
design flaw at the source code block level. First, we apply
a lightweight method body decomposition into blocks by
employing a third-party technique described by Yang et al. [6].
Next, we use the detection strategy introduced by Lanza and
Marinescu for the identification of envious methods [2], and
applying it at the block level in order to detect envious pieces
of code. Finally, we try to group together envious blocks with
their neighbours to obtain more accurate envious fragments.
The paper is organized as follows. Section II presents some
related work. Section III describes the inner workings of our
solution with some few additional implementation details in
Section IV. Section V illustrates our findings after applying
our approach on real life code, while Section VI concludes
our paper and elaborates future work ideas.
II. R ELATED W ORK
Several different approaches for Feature Envy design flaw
detection are described in the state-of-the-art literature. In [2]
a metric-based approach is applied. Three software metrics
are used to capture structural properties of methods, relevant
in the context of Feature Envy e.g., the number of attributes
from external classes accessed by an operation. Next, for
each method, these measurements are classified as normal or
abnormal by comparing them to some threshold limits. Finally,
a method is considered envious when all its metric values are
abnormal.
544
 In the same metric-based spirit, in [3], the authors introduce
a distance metric between methods and classes based on
member accesses. In essence, methods that are “closer” to
other classes rather than their declaring class are identified as
“desiring” to be moved elsewhere.
A different approach for Feature Envy detection is intro-
duced in [4]. The author uses the commit history to detect
operations more frequently changed together with operations
from other classes rather than to methods from the same class.
Yet a different detection methodology is presented in [5]. The
potential envious methods are identified as those that are more
similar to other classes, rather than the classes where they are
declared in, from the point of view of the involved textual
concepts e.g., identifiers found in their source code.
All these approaches detect the Feature Envy design issue
at method level. By contrast, we propose the detection of
the problem at the level of blocks of code inside the method
bodies. For the actual detection, we use the same metric-based
approach described in [2], but we apply it at the more fine-
grained block level.
From the granularity point of view, our work is related to
several other approaches trying to split long methods into
smaller pieces of code that could be extracted in separate
operations. For this purpose, in [7], a methodology based
on program slicing is presented. On the one hand, it tends
to be more accurate as it is based on a detailed program
representation (i.e., program dependency graph) but, on the
other hand, more intensive from a computational point of view.
At the other side of the spectrum, the method splitting problem
is also addressed in [6], but in a more lightweight manner,
sacrificing precision. In essence, an operation is broken into
blocks following the nesting of compound statements (e.g., if,
for). Next, refactoring opportunities are identified by consid-
ering the length of a block and the number of input and output
values required if the block would be extracted into a separate
function.
In our approach, we chose to be lightweight and we em-
ployed the same method decomposition approach as in [6].
However, by contrast to both aforementioned approaches, there
is an additional differentiating aspect. That is, the previous
methodologies could potentially identify and extract a piece of
code from a long method that would actually solve a correlated
Feature Envy design problem. As showed in [7], one such case
has actually been encounter during their evaluation. However,
in general, it cannot be know if the Feature Envy issues
from a long method would properly be extracted into separate
strategy from [2]. Finally, we try to group envious blocks with
their neighbors in order to form larger envious fragments. In
the following, we present each of these phases in detail based
on the accompanying example from Listing 1.
Listing 1. Accompanying example
1 public void p e r s i s t ( Object o ) {
2 if (o instanceof Circle ) {
3 t h i s . s t r e a m . w r i t e I n t ( ( ( C i r c l e ) o ) . getX ( ) ) ;
4 t h i s . s t r e a m . w r i t e I n t ( ( ( C i r c l e ) o ) . getY ( ) ) ;
5 t h i s . s t r e a m . w r i t e I n t ( ( ( C i r c l e ) o ) . getR ( ) ) ;
6 }
7 i f ( o instanceof Rectangle ) {
8 t h i s . s t r e a m . w r i t e I n t ( ( ( R e c t a n g l e ) o ) . getX1 ( ) ) ;
9
10 t h i s . s t r e a m . w r i t e I n t ( ( ( R e c t a n g l e ) o ) . getY1 ( ) ) ;
11 t h i s . s t r e a m . w r i t e I n t ( ( ( R e c t a n g l e ) o ) . getX2 ( ) ) ;
12 t h i s . s t r e a m . w r i t e I n t ( ( ( R e c t a n g l e ) o ) . getY2 ( ) ) ;
13 }
14 }
A. Decomposition into blocks
In essence, the block of statements representing the entire
body of a method is recursively split into sub-blocks following
the nesting structure of the compound statements such as if,
for, etc. If a block does not contain compound statements it
will become a basic block of statements corresponding to a
leaf in the resulted hierarchical structure. However, there is an
additional splitting heuristic that is used in [6]: a block is split
into sibling sub-blocks at the positions of each blank line.
For the example presented in Listing 1 the corresponding
hierarchy of blocks in presented in Figure 1. As it can be seen,
we have 3 leaves here corresponding to the statements in lines
3-5, 8 and 10-12, the last two being the result of the empty
line 9.
B. Detecting envious leaf blocks
In this step, we apply on each leaf block the Feature
Envy detection strategy introduced in [2] and summarized in
Formula 1.
IsEnvious(B) = AT F D(B) > F EWAT F D
∧ LAA(B) < M AX P ERCEN TLAA (1)
∧ F DP (B) ≤ F EWF DP
Method Block
Lines 1-14
IfStatement IfStatement
Lines 2-6 Lines 7-13

methods using these techniques because they are not Feature

Envy aware. By contrast, we try to highlight envious fragments
within methods (long or not) that might be extracted into Then Block Then Block
separate operations to directly address Feature Envy issues. Lines 2-6 Lines 7-13

III. D ETECTING E NVIOUS B LOCKS OF C ODE

BasicStatement BasicStatement BasicStatement
Our methodology is composed of three phases. First, we Block Block Block
split the body of the analyzed method into a hierarchical Lines 3-5 Lines 8-8 Lines 10-12

structure of blocks according to the technique used in [6].

Next, for each leaf block, we apply the Feature Envy detection Fig. 1. The hierarchy of blocks for the example in Listing 1

545
 The metrics at the block level are similar to those defined
at the method level in [2]. ATFD (Access To Foreign Data)
represents the number of attributes from other classes accessed
from a block directly or indirectly via accessor methods.
LAA (Locality of Attributes Accesses) represents the relative
number of local attributes (e.g., of the class declaring the
method containing the block) accessed by that block. FDP
(Foreign Data Providers) represents the number of classes in
which are defined the foreign attributes accessed by the block
in accordance to the ATFD metric.
We mention that in the current state of our work, we
use the same form of the Feature Envy detection strat-
egy as implemented in the I P LASMA analysis tool [2],
[8], including the threshold values (i.e., F EWAT F D = 2,
M AX P ERCEN TLAA = 1/3 and F EWF DP = 2). Nev-
ertheless, some adaptations may be required in the future for
tuning the strategy accuracy at the block level e.g., different
thresholds, additional metrics.
By applying the aforementioned detection strategy on the
leaf blocks from Figure 1, we can identify as envious the two
leaves associated to lines 3-5 and 10-12. For instance, the first
block accesses 3 foreign attributes via accessors (i.e., getX,
getY and getR), all from the Circle class. This means its ATFD
is 3 and its FDP is 1. Additionally, the first block accesses 1
local field i.e., stream and thus, its LAA is 0.25.
What is important to observe here is that by applying the
detection strategy at the method level, we could also identify
the entire method as envious. However, in that case we would
find 2 distinct data providers, namely the Circle and the
Rectangle classes. Thus, at the method level, we cannot be sure
where to move the entire operation to solve the Feature Envy
problem. By contrast, using our approach, we can observe that
the block for lines 3-5 envies the Circle class while the block
for lines 10-12 envies the Rectangle class. Thus, we can easily
conclude where should these fragments be moved i.e., the first
in the Circle class the second in the Rectangle class.
Unfortunately, at a closer look, one may observe that the leaf
block containing only line 8 is not detected as envious because
its ATFD is just 1. However, conceptually, it is similar to the
envious leaf containing lines 10-12. The way we address this
problem is the subject of the following subsection.
C. Grouping envious block with neighbours
As a result of the second phase of our analysis, the envious
leaf blocks are detected. However, these separate leaves may
actually form larger envious fragments. For instance, the leaf
containing lines 10-12 (see Listing 1) should be grouped with
the block corresponding to line 8 to form a larger envious piece
of code. Different grouping heuristics could be imagined here
but, at this moment, we define the following two ones. Both
are applied during a post-order traversal of the block structure.
a) Breadth grouping: When an envious block is found,
we try to group it with its previous siblings, one by one.
In each step, a grouping is accepted if i) the resulted group
of blocks is still detected as envious by the Feature Envy
detection strategy and ii) if the set of foreign data provider
546
classes of the resulted fragment is included in the set of foreign
data providers of the initial envious block. The procedure stops
when all previous siblings are included or at the first non-
acceptable grouping attempt. Similarly, then we try to create an
even larger fragment by considering for grouping the siblings
occurring after the initial envious block1 .
b) Bottom-up grouping: When all the children of a parent
node are grouped together by the previous heuristic, we try
to also include the parent in the grouping to form an even
larger envious fragment. The extension is performed under
the same conditions, as mentioned in case of the previous
heuristic: the Feature Envy detection strategy must still be
trigger when applied on the larger fragment and its set of
foreign data providers must be included in the set of providers
of the children group. We mention that the case when a parent
has just one child (that is also envious) is similarly treated by
this heuristic.
For the example in Listing 1 / Figure 1, the leaf cor-
responding to lines 10-12 was detected as envious in the
previous analysis step. Its foreign data provider set of classes
is {Rectangle}, being the single external class from which
the fragment gathers data. As a result of the breadth grouping
this leaf is combined with its sibling leaf corresponding to line
8. It is easy to observe that the larger fragment (i.e., lines 8-
12) is still detected as envious by the Feature Envy detection
strategy and that its set of foreign data providers remains
the same i.e., {Rectangle}. Thus, the grouping is accepted
and the entire larger fragment is considered envious. Next,
since all the children of the then-block from the second if are
grouped together, the second heuristic takes action. The parent
node does not add any supplementary statements and thus,
the Feature Envy detection strategy is still triggered on the
larger fragment and the set of data providers is not changed.
Consequently, the entire then-block is considered envious.
In the same manner, the bottom-up grouping heuristic marks
as envious the fragments corresponding to each of the two if
statements i.e., the fragments in lines 2-6 and 7-13, respec-
tively. Note that the if conditions do not hinder the detection of
those larger blocks of code as envious. However, it is important
to observe that the two ifs will not be combined into an even
large piece of code. That is because their foreign data provider
sets are different: for the first fragment it is {Circle}, while for
the second one it is {Rectangle}. Thus, the second condition
for applying the breadth grouping does not hold.
IV. I MPLEMENTATION
The approach we propose in this paper was implemented
in a prototypical E CLIPSE plugin called M ETHOD D EFRAG -
MENTER 2 (see Figure 2). The detected envious fragments are
presented to the user in a dedicated view with additional infor-
mation, such as the values of all involved metrics. Moreover,
the user can ask the plugin to highlight the envious fragments
in the source code editor, using different colors.
1 The grouping order may influence the final result but, for the moment, we
do not consider this aspect.
2 https://bit.ly/2NHKaIl
 Fig. 2.
TABLE I
C HARACTERISTICS OF THE ANALYZED SYSTEM
Name Classes Methods Lines of Code
jFreeCharta 980 11 018 123 110
a http://www.jfree.org/jfreechart/
The hierarchical structure of blocks is constructed by vis-
iting the ASTs of the investigated methods as provided by
the E CLIPSE JDT infrastructure. Similarly, the values of the
involved software metrics are computed by visiting the ASTs
of the statements forming the measured block and using the
cross-reference mechanism provided by E CLIPSE to uniquely
identify the accessed entities.
V. E VALUATION
The main goal of our very first evaluation was to establish
if the proposed approach is feasible in spotting Feature Envy
areas within the body of methods in a better way than detecting
their entire bodies as envious. As a second objective, we
wanted to observe real code situations in order to identify
ways to enhance our detection approach and the accuracy of
the envious fragment boundaries.
For this purpose, we used I P LASMA [8] in order to detect
object-oriented design flaws in the system from Table I. From
the resulted report, we randomly selected 40 methods exhibit-
ing a Feature Envy, a Brain Method, an Intensive Coupling
or any combination between these flaws. We also included
the last two kinds of problems because of the close relations
M ETHOD D EFRAGMENTER at Work
TABLE II
C OMPARISON OF THE DETECTION RESULTS
I P LASMAdetection Same Block-level detection
more relevant relevance more relevant
10 7 9
between them and the Feature Envy issue as described in
[2] e.g., a Brain Method might partially be a Feature Envy.
Next, we manually investigated these cases and, to the best of
our understanding, we selected only those containing at least
some relevant envious portion. We mention that the eliminated
methods were in general instances of the Brain Method and /
or Intensive Coupling flaws and nothing was detected by our
approach in these cases.
As a result, we got 26 relevant methods to be considered
in the remaining of our investigation. Next, we manually
compared the results produced by I P LASMA and by our
approach and, to the best of our understanding of the source
code, we established whose detection is more relevant. To do
that we tried to determine if an entire suspected method is
really envious, if only a portion of it is envious, etc. and
we compared our assessment with the reports provided by
I P LASMA and by our tool. The results are summarized in
Table II and discussed in details in the remaining of this
section.
In 7 cases (i.e., Same relevance category), we found that
I P LASMA and our detection approach provide the same result.
547
In general, this means that the entire method bodies are found
as envious by both techniques. However, in 2 cases, only
parts of the corresponding methods looked actually envious
and thus, our mean of analysis needs some improvements.
The problem is that we group blocks without effectively
considering their correlation at the semantics level. Sure, this
is difficult to be done at the current level of abstraction of
the code. However, one possible improvement would be to
consider the visibility domain of the variables involved in
accessing the foreign data providers for better block grouping
and splitting.
In 10 cases, the results given by I P LASMA were better. In
almost all these situations, the involved methods looked as
Feature Envy instances at the entire method body level. How-
ever, none of these cases were detected by our approach. The
problem is that we decompose the code into leaf blocks that are
far too small, many times containing just one statement. Thus,
the Feature Envy detection strategy does not get activated and,
consequently, nothing is grouped to form larger fragments.
Several possible improvements are envisioned here. On the
one hand we could stop the block splitting procedure when a
block becomes too small from the number of statements point
of view. Another idea would be to vary the detection strategy
thresholds based on the size of the analyzed blocks.
Finally, in 9 cases, we considered the results provided by our
approach to be more relevant. In some situations, I P LASMA
also detected a Feature Envy at the entire method level.
Nevertheless, our approach managed to better indicate towards
the envious sub-fragments. More important however, in 6 cases
related to the Brain Method / Intensive Coupling flaws, only
our approach detected the presence of some relevant envious
sub-fragments in the corresponding methods. Thus, from the
perspective of the Feature Envy detection in I P LASMA, these
are false-negative cases. As a result, we can conclude that our
approach looks feasible, relevant and might be used even in
this stage of development as a complementary technique for
I P LASMA when detecting envious sub-fragments in methods
affected by Brain Method and/or Intensive Coupling design
problems.
We would like to also mention that while in some cases the
boundaries of the detected envious fragments looked exact,
in many situations further improvements are needed in this
direction. The fragments looked a little too long or too short
and thus, the grouping and/or block splitting mechanisms need
some refining. This would not be an easy task since, due
to our limited understanding of the case study code, it is
relatively difficult to exactly and objectively establish the right
boundaries.
Last, but not least, we would like to mention that we
encountered a situation when two non-adjacent fragments of
the same method looked correlated with respect to the same
envied class. Thus, our grouping mechanism might have to be
extended to also permit to capture this kind of cases (and not
only correlation between adjacent blocks as currently does).
548
VI. C ONCLUSIONS AND F UTURE W ORK
In this paper we introduced an approach for the detection of
the Feature Envy design flaw at a smaller level of granularity
than other approaches, namely at the level of blocks of code.
In essence, a method body is split into a hierarchical structure
of blocks. Next, the corresponding detection strategy is applied
to identify envious leaf blocks. Finally, these envious blocks
are extended in order to better localize the Feature Envy issue
in the body of the analyzed method.
Our initial evaluation showed that the technique is feasible
and can spot the envious areas within a method even if with
not a very high accuracy regarding the boundaries of these
areas. However, at least in cases where Brain Method and/or
Intensive Coupling flaws hiding the envious sub-method parts,
our approach behaves promisingly and better than I P LASMA.
In the next period of time we will try to address the issues
and the improvement directions mentioned in Section V: han-
dling the detection of very small envious blocks of code and
improving the block splitting / grouping algorithms to detect
more accurate boundaries for the envious fragments. Next,
we also consider other possible improvements, for instance,
ranking the findings (i.e., the envious sub-fragments) to spot
the most important and more feasible ones from the Feature
Envy correction strategy point of view (e.g., what fragments
would require a smaller number of parameters if extracted
into a separate operation?). For this purpose, we may even
restrain the envious block detection by adding supplementary
metrics in the Feature Envy detection strategy. The special
case of polymorphic interactions between a method and a data
provider is also considered for future work and it will probably
involve the analysis of the entire class hierarchy to identify the
actual data source. Last but not least, we will reevaluate our
technique from the accuracy point of view on a higher number
of problem instances and case study programs, ideally with the
involvement of real users.
R EFERENCES
[1] M. Fowler, K. Beck, D. Roberts, and E. Gamma, Refactoring: Improving
the Design of Existing Code. Addison-Wesley Professional, 1999.
[2] M. Lanza and R. Marinescu, Object-Oriented Metrics in Practice.
Springer Verlag, 2006.
[3] N. Tsantalis and A. Chatzigeorgiou, “Identification of move method
refactoring opportunities,” IEEE Transactions on Software Engineering,
vol. 35, no. 3, pp. 347–367, May 2009.
[4] F. Palomba, G. Bavota, M. D. Penta, R. Oliveto, D. Poshyvanyk, and
A. D. Lucia, “Mining version histories for detecting code smells,” IEEE
Transactions on Software Engineering, vol. 41, no. 5, pp. 462–489, May
2015.
[5] F. Palomba, A. Panichella, A. D. Lucia, R. Oliveto, and A. Zaidman, “A
textual-based technique for smell detection,” in Proceedings of the 24th
IEEE International Conference on Program Comprehension (ICPC), May
2016, pp. 1–10.
[6] L. Yang, H. Liu, and Z. Niu, “Identifying fragments to be extracted
from long methods,” in Proceedings of the 16th Asia-Pacific Software
Engineering Conference. IEEE, 2009, pp. 43 – 49.
[7] N. Tsantalis and A. Chatzigeorgiou, “Identification of extract method
refactoring opportunities for the decomposition of methods,” Journal of
Systems and Software, vol. 84, no. 10, pp. 1757–1782, Oct. 2011.
[8] C. Marinescu, R. Marinescu, P. F. Mihancea, and R. Wettel, “iPlasma:
An integrated platform for quality assessment of object-oriented design,”
in Proceedings of the 21st IEEE International Conference on Software
Maintenance (ICSM) - Industrial and Tool volume, 2005.