2012 19th Asia-Pacific Software Engineering Conference

SATA Workshop

Preprocessing of Metrics Measurement Based on Simplifying Program Strucutres
Yui Sasaki, Tomoya Ishihara, Keisuke Hotta, Hideaki Hata,
Yoshiki Higo, Hiroshi Igaki, Shinji Kusumoto
Graduate School of Information Science and Technology, Osaka University,
1-5, Yamadaoka, Suita, Osaka, 565-0871, Japan
Email: {s-yui,t-ishihr,k-hotta,h-hata,higo,igaki,kusumoto}@ist.osaka-u.ac.jp
methods should be broken up into simple methods [11]. This
operation is known as Extract Method refactoring, which isone of the most popular refactorings, and is often performed
with other refactorings [12]. Because identifying the place
to be refactored is the ﬁrst step in refactoring process, longor complicated methods are often identiﬁed with Lines Of
Code or Cyclomatic Complexity.
In order to perform activities of software maintenance,
we must understand source code of the maintaining software. However, software understanding itself is costly. A
fundamental task in software maintenance is reading andunderstanding source code [13], [14], [15]. Consequently,
identifying low-understandability modules and improving
their understandability lead to efﬁcient software maintenancein the future.
However, Cyclomatic Complexity does not always represent the low-understandability of source code. Buse andWeimer investigated code readability with several software
metrics [16]. They reported that though the low-level code
features and well-known metrics (code churn, past bugs,
warnings with a static analysis tool) had a signiﬁcant levelof correlation with code readability, Cyclomatic Complexity
was not strongly related to readability. Also, Jbara et al. mentioned that there were some functions including successive
single-instructions such as case-entries in switch-statements
and if-statements in Linux Kernel, and these structures did
not reﬂect perceived complexity [17]. Moreover, CyclomaticComplextiy often underestimates the understandability ofmodules because it does not count jump instructions suchas break- and continue-statements which break the “straightline” ﬂow of execution [18]. As described above, CyclomaticComplexity does not always work well in the context ofﬁnding low-understandability modules. Though there aretools that measure the modiﬁed Cyclomatic Complexity suchas pmccabe [19], there is no empirical study with these tools.
As well as Cyclomatic Complexity, Lines Of Code metricdoes not always indicate understandability of source code.
The authors think that, one factor of it is the presence ofrepeated structures. For example, a long method is considered as a typical target of Extract Method refactoring.
However, if it consists of a repetition of similar operations,its cohesion should not be low. For example, a long method
initializing GUI parts includes many assignment statements.

Abstract—In software maintenance, grasping characteristics
of software systems by metrics measurement is a basic activity.
However, metrics do not always represent characteristics ofsoftware systems. For example, Cyclomatic Complexity is ametric counting the number of branches in a given module,
and it does not consider its content. One factor that Cyclomatic Complexity becomes large is the presence of repeatedstructures such as consecutive if-else structures. However, if
such a structure is a repetition of simple operations, humans
would not recognize a difﬁculty to understand the sourcecode. In this paper, we propose performing preprocessing for
metrics measurement and a methodology of the preprocessing.
The proposed preprocessing simpliﬁes repeated structures insource code. By applying the proposed preprocessing to metrics
measurement, we can ﬁnd low-understandability modules more
efﬁciently. Also, we compared results of metrics measurementwith and without the proposed preprocessing on open source
software systems. As a result, we conﬁrmed that metrics
measurement with the proposed preprocessing was more useful
to ﬁnd low-understandability modules than without it.
Keywords-Empirical Study, Metrics Measurement, Software
Maintenance

I. INTRODUCTION
Measuring software is a fundamental technique of empirical software engineering. For example, many software
metrics have been widely studied and proposed in fault
prediction studies [1], [2]. Mining Software Repositories
ﬁeld has explored software repository data and has proposed
many historical metrics for fault prediction models [3], [4].
Recent studies have shown the usefulness of such historicalmetrics compared to traditional complexity metrics [5], [6].
McCabe’s Cyclomatic Complexity is one of the mostpopular complexity metrics [7]. A variety of empiricalstudies revealed the usefulness of Cyclomatic Complexity.
It is said, however, Cyclomatic Complexity does not exhibit
the proper complexity in object-oriented systems. Chidamber
and Kemerer deﬁned six complexity metrics in objectoriented designs, and Basili concluded that these metrics
were useful to identify fault-prone modules than CyclomaticComplexity [8], [9].
Not only fault prediction studies, but detecting refactoring
candidates also have used software metrics [10]. Refactoringis a technique of improving the structure of a program
without changing its external behavior. For example, long orcomplicated methods are less maintainability, and so these1530-1362/12 $26.00 © 2012 IEEE
DOI 10.1109/APSEC.2012.59

120

1: public final Object getValoreIndirizzobenefattotrans(...) {...
if() { ... if() { ... if() { ... if() { ...
124:
if (soggetto != null) {
...
128:
else
129:
{
130:
ArrayIterator iter = ...;131:
if (iter!=null && iter.size()>0) {132:
iter.reset();133:
IfIndirizzo recapito = ...;
134:
if(...)
135:
return ...;
136:
else return null;
137:
}
138:
else
139:
return null;
140:
}
141:
}
142:
else return null;} } } }
189: }

if (…) {state = X;
} else if (…) {state = Y;
} else {state = Z;}
Figure 3.

if
Else

Then

Else

if
Then

Else

if
Then

Else

: assignment

Transformation of else-if Statements

The value 112 of its Cyclomatic Complexity indicates thatthe structure in this method has lower understandability
than Figure 1(a). Though the method certainly includes
many branches, it is not difﬁcult to understand because ofrepetition of simple instructions.
In this paper, we propose a new technique for measuringlower metric values in such a case of Figure 1(b). The
key idea is folding repeated structures. If a method has
repeated structures such as if-statements in Figure 1(b),the structures are folded as a single structure. Here after,
we use a term simpliﬁed source code, which means sourcecode where all the repeated structures in the original sourcecode are folded. These operations are a preprocessing of
metrics measurement. Applying the proposed preprocessing,the value of Cyclomatic Complexity of Figure 1(b) becomes
lower than the value of Figure 1(a).

(a) a method including deep nest structures
1: public static int getColumnIndex(final String sColumnName)
2: {3:
if (sColumnName.compareToIgnoreCase(...) == 0)4:
return NDX_TI_ID_TITOLO;
5:else if (sColumnName.compareToIgnoreCase(...) == 0)6:return NDX_TI_ID_COMPAGNIA;...
204:
else if (sColumnName.compareToIgnoreCase(...) == 0)
205:
return NDX_FI_DESC_FILIALE;
206:
return -1;
207: }

III. PROPOSED PREPROCESSING(b) a method including repeated structures
Figure 1.

if
Then

Herein, we describe the operation of folding repeatedstructures, which is the proposed preprocessing of metrics
measurement. The process is performed as follows:1) constructing ASTs from input source code;2) folding repeated structures on ASTs;3) creating simpliﬁed source code from the folded ASTs.
Figure 2 shows how the source code of Figure 1(b)is manipulated by the proposed preprocessing. By using
Figures 2 and 1(b), we explain the details of the proposed
preprocessing.

Motivating Example

Such assignment statements can be considered as a repetitionof similar operations. Also, we do not consider that a partof such a method should be extracted as a new method for
reducing method size.
In this paper, we focus on the context that a user would
like to ﬁnd low-understandability modules, and propose
a preprocessing of metrics measurement for ﬁnding such
modules efﬁciently. In order to investigate the usefulness ofthe proposed preprocessing, we conducted an experiment on
approximately 13,000 open source software systems. In theexperiment, we compared results of metrics measurementwith and without the proposed preprocessing. As a result, we
conﬁrmed that low-understandability modules were foundmore efﬁciently with the proposed preprocessing than without it.

Phase1. Constructing ASTFirst, we construct ASTs from input source code. A
remarkable point is that, in the proposed preprocessing, elseif structures following if-statement as shown in Figure 1(b)are transformed. The transformation consists of (1) removing
a node “Else” if there is only a node “If” following the node
“Else”, (2) connecting parent and child nodes of the removed
node. Figure 3 shows an example of the transformation. By
using the transformation, we can regard else-if structures as
repeated ones in the Phase2.
Our approach does not focus on the details of statements
such as variable names or conditional expressions. We do
not consider AST nodes corresponding to such elements insource code.

II. M OTIVATING E XAMPLE
Figure 1(a) is a Java method, which has deep nest structures with many if-statements. The Cyclomatic Complexityof the method becomes 33, which reperesents this method
has low understandability.
We found another method as shown Figure 1(b) whose
Cyclomatic Complexity was 112 in the same software.

121

InputOutput…
public static int getColumnIndex(…){
if (…)
return NDX_TI_ID_TITOLO;
else if (…)
return NDX_TI_ID_COMPAGNIA;
else if (…)
return NDX_TI_ID_NODO;
else if (…)
return NDX_TI_ID_CAUSALE;…
else if (…)
return NDX_FI_DESC_FILIALE;
return -1;
}
…

Root

Root

Class

Class

MethodMethod
if

then

then

returnreturn*N: weight

MethodMethodreturn...

…
public static int getColumnIndex(…){
if (…)
return NDX_TI_ID_TITOLO;
return -1;
}
…

if

then

then

returnreturnreturn*112

Phase3112 subtrees

Phase.2

Phase.1

Figure 2.

Proposed Preprocessing for Figure 1(b)compared nodes

compared nodes

compared nodes

repeated structure

repeated structure

repeated structure(a) pairs of leaves(b) pairs of branches
Figure 4.

(c) pairs of sequential nodes

Examples of Repeated Structures

*2

if

if

if

if

if

if

if

Then

Then

Then

Then

Then

Then

Then

Then

*2

*2

*2

*2

*2
fold

fold

Figure 5.

fold

if

: method invocation

Example of Folding AST

Phase2. Folding Structures

the criteria, it would be similar to each other. Consequently,
we can regard structures of Figure 4(c) as repeated ones.

AST sibling nodes are sorted in the order of the appearance on the source code. If there are consecutive similar
structures in sibling nodes, they are regarded as repeatedstructures. If a pair of nodes satisﬁes the criteria in Table I,
the nodes would be regarded as similar to each other. We
describe “weight” in Table I later. ASTs in Figure 4(a) and4(b) are regarded as repeated structures based on the criteria.
In addition, not only a single node but also sequential
nodes are compared as one-side of the pair in AST siblingnodes. For example, in the following source code, there
are consecutive two statements (assignment statement andmethod invocation statement).

Folding repeated structures consists of two operations,which are (1) removing all the elements of the repetitions
except the ﬁrst element, and (2) adding the weight of thenumber of elements to the ﬁrst element.
There are nested repeated structures in the source code.
For example, in the following source code, there are repetitions of method invocations and repetitions of if-statements
including the method invocations.

comparator = new ObjectIdentifierComparator();cb.schemaObjectProduced( this, "2.5.13.0", comparator );comparator = new DnComparator();cb.schemaObjectProduced( this, "2.5.13.1", comparator );Table IC RITERIA FOR S IMILARITY OF N ODE
compared nodesa pair of leaves
a pair of branches

In order to handle repetitions of such multiple statements,
if each pair of nodes in a pair of sequential nodes satisﬁes

122

criteria for similarity
type of statements and weights are the same
its subtrees are isomorphic

if (null != storepass) {cmd.createArg().setValue("-storepass");cmd.createArg().setValue(storepass);}
if (null != storetype) {cmd.createArg().setValue("-storetype");cmd.createArg().setValue(storetype);
}

4,500

CC

4,000

FCC

3,500

value of metrics

3,000

In the case of nested repeated structures, the folding operation is applied to nodes in order from leaf to root. In
this example, ﬁrstly method invocations are folded, then ifstatements are folded.
This process is achieved by a postorder traversal. If a
traversed node contains children, we get them. Then, if we
ﬁnd a pair of similar (sequential) nodes in the children, they
are folded. These operations are repeatedly performed until
there are no similar nodes on sibling nodes. Figure 5 shows
how the above source code is folded.
There are various repeated structures in source code suchas introduced by [20]. We conﬁrmed that all of the repeatedstructures in [20] were folded with this approach.
Though Figure 1(b) has many branches, each branch node
has similar statements as its children. Therefore, all thestructures are folded.

2,500
2,000

1,500
1,000
500
0

100

200
300
method number

400

500

(a) Cyclomatic Complexity
14,000LOC
12,000FLOC
value of metric

10,000

8,000
6,000
4,000
2,000

0
100

Phase3. Providing Simpliﬁed Code200
300
method number

400

500

(b) Lines Of CodeFinally, the proposed preprocessing generates simpliﬁed
source code from the simpliﬁed ASTs.

Figure 6.

Difference of Metrics Values

IV. CASE STUDY
case-entry in switch-statement
do-statement• for-statement• foreach-statement• if-statement• catch-statement in try-statement• while-statement
Also, Lines Of Code was measured without comment
lines and blank lines. In the remainder of this section,
metrics used in this experiment are called as shown in TableIII.
•

We implemented a prototype tool for Java source code,and evaluated the proposed preprocessing by applying thetool to about 13,000 software systems (see Table II), which
are open to the public in [21]. In this evaluation, we
calculated some metrics for each method in all the target
software. The purpose of the case study is to reveal theanswers to following questions.
1) Do results of metrics measurement change by using
the proposed preprocessing?
2) Is there any relationship between metrics measurement
result and understandability of the source code?
In the remainder of this section, we describe experimental
results and answers for each question.

•

Ex1.Comparison between Metrics Values

In this experiment, we measured Cyclomatic Complexity
and Lines Of Code. Cyclomatic Complexity was measured
by counting branches in source code. We regarded that thefollowing blocks were branches.

At ﬁrst, we compared values between metrics with andwithout the proposed preprocessing for each method. Figure
6 shows the top 500 methods on all the target software
without the proposed preprocessing. We found that particularly high CC or LOC values were greatly reducedwith the preprocessing. That means these methods include

Table IIOVERVIEW: UCI S OURCE C ODE DATA S ETSTable IIITARGET M ETRICS

SetUp# of software# of methods
total lines of code

13,19318,366,094
361,663,992

without the preprocessing
with the preprocessing

123

Cyclomatic Complexity
CC
FCC

Lines Of Code
LOC
FLOC

28

30

CC
FCC

25

Correct set

25
21# of methods

value of metric

200
180
160
140
120
100
80
60
40
20
0
100

200
300
method number

400

500

CC

FCC

LOC

FLOC

20
15

15

15
10

10

10
3

5

0

Figure 7.

Difference of Metrics Values on One SoftwareA

Figure 8.

many repeated structures. The highest CC is 4,371, and its
method includes 200 if-statements. 191 out of the 200 ifstatements have only one large switch-statement including somany case-entries. The case-entries in each of such switchstatements were folded.
Each software has a different gap between CC and FCC
measurement. For example, some software have few methods including repeated structures, and the others have manymethods including repeated structures as shown in Figure
7. Though this software has many methods whose CC areover 100, almost all of them have repeated if-structures, andso those FCC are only 5. Furthermore, a method with thehighest FCC ranks at the 455th in the CC order, which meansthat it is not easy to ﬁnd this method with CC.
In order to grasp how measurement results for every
target system were changed by the proposed preprocessing,
we used an indicator, ConcordanceRate. ConcordanceRatemeans the rate how measurement results with and without the preprocessing share the same modules in top n.
ConcordanceRate for Cyclomatic Complexity is deﬁned as
the following formula.
ConcordanceRate(n) =

B

C

D

subject

E

F

G

H

Comparison between Human Consideration and Metrics

30# of methods

25
20
15
CC
FCC
Ideal

10
5
0
1

51

101

151

20%

201
n

251

301

351

(a) Cyclomatic Complexity
30# of methods

25
20
15
LOC
FLOC
Ideal

10
5
0
1

51

101

20%

151

201
n

251

301

351

(b) Lines Of Code
Figure 9.

|CC(n) ∩ FCC(n)|nThe Number of Correct Methods in Top n1) Every subject judge whether each method is difﬁcult
to understand or not.
2) Every method judged as difﬁcult to understand iscalled a correct method, and its set is called correctset.
3) Methods in the target systems are sorted in the orderof each metric with and without the proposed preprocessing. We compare the number of correct methods
included in top 20% of the sorted methods.
The subjects judged all the methods by browsing thesource code of them. We did not provide metrics values tothe subjects during the experiment. We selected not so large
software from 13,000 software systems as the target because
the subjects checked the source code manually. The target
software is JCap, which includes 389 methods. The valuesof ConcordanceRate of Cyclomatic Complexity and Lines
Of Code for this software are 69% and 67%, respectively.
Figure 8 summarizes the result. In the case of subject“A”, there are 28 correct methods. The value of Y-axis
represents the number of correct methods included in the top
20%. As shown of this graph, both Cyclomatic Complexity

CC(n) and FCC(n) are sets of methods that are top nin the CC or FCC order, respectively. The more there arecommon methods between CC(n) and FCC(n), the higher
ConcordanceRate becomes. We determined the threshold n
as the number of the top 20% methods for each software.
If there is no difference between top 20% CC and top 20%
FCC methods, ConcordanceRate becomes 1.
Investigating for all the target software, we found thatabout 85% of the target software had at least one different
method in their top 20%.
Ex2.Comparison between Understandability of Source Codeand Metrics Values
We evaluated metrics with the preprocessing based on thehuman consideration. In this experiment, 8 people (faculty
staffs and students) in the department of computer science ofOsaka University were joined as subjects. This experiment
was conducted along with the following steps.

124

40

CC

35

8
7

FCC
6

# of subjects
25

5

20

4

15

3

10

2

5

1

0

# of subjects

value of metric

30

0
1

51

101

151

201

method number(a) Cyclomatic Complexity
LOC
FLOC

value of metric120# of subjects

8
7

6

100

5

80

4

60

3

40

2

20

1

0

# of subjects

160
140

0
1

51

101

151

201

method number(b) Lines Of Code
Figure 10.

Relationship between Metrics Value and The Number of Subjects

V. DISCUSSION

and Lines Of Code with the preprocessing present morecorrect methods than without it in the top 20%. That is,for subject “A”, the preprocessing is useful to detect lowunderstandability methods efﬁciently. Totally, in the case of
Cyclomatic Complexity, for 7 out of 8 subjects, the numberof correct methods with the preprocessing is larger than
without it. On the other hand, in the case of Lines Of Code,the preprocessing is more useful for only 2 out of 8 subjects.
For 4 out of remaining 6 subjects, both results with andwithout the preprocessing included all the correct methods,
so that we could not see differences between them.

Figure 10 shows metrics values of all the methods included in the target system of Ex2. In addition, we plotted
the number of subjects who judged the method as difﬁcult
to understand. In X-axis, the methods are arranged in thedescending other of FCC/FLOC. We conﬁrmed that there
was a correlation between FCC/FLOC and the number ofsubjects who judged the method as difﬁcult.
However, there are some outliers. First, there are falsepositive methods. Though these methods had high FCC or
FLOC values, all the subjects judged as not difﬁcult tounderstand. For example, there is a method which includes 3
switch-statements, and the number of case-entries in each of
the switch-statements is different. This method has high FCC
and FLOC, because 3 switch-statements are not regarded as
repeated structures. As shown this example, difference ofthe repeat count may be not signiﬁcant for humans. Hence,
it would be required not to consider the difference of therepeat count.
Also, there are other kinds of false-negative methods.
These methods were judged as difﬁcult to understand bysome subjects, and their metrics values were reduced by applying the preprocessing. From this result, there is possiblethat the length of source code affects to understandability.
Simpliﬁed source code has no information about the repeat
count and metrics values of the original source code. Hence,
it is necessary to use not only metrics values with the
preprocessing but also ones without the preprocessing or

Next, we investigated the number of correct methods
included in top n by changing n. Figure 9 shows theinvestigation results for subject “B”. The dotted line is
the ideal curve, which means that all the correct methods
appear in the top without including other methods. We cansee that (1) the curve of FCC is nearer than CC, and (2)the curve of FLOC is nearer than LOC, respectively. Thatmeans the preprocessing is useful for efﬁcient detection of
low-understandability methods. Especially, in the case of
Cyclomatic Complexity, there is a signiﬁcant difference withand without the preprocessing. In the top 10 methods, only
2 correct methods were included without the preprocessing
whereas 9 correct methods were included with it. We conducted the same investigation for the other subjects. As aresult, for 7 out of 8 subjects, we found that the proposed
preprocessing was useful for detecting low-understandability
methods efﬁciently.

125

R EFERENCES

the other metrics related to readability of source code for
identifying low-understandability source code.

[1] T. Menzies, J. Greenwald, and A. Frank, “Data mining static
code attributes to learn defect predictors,” IEEE Transactions
on Software Engineering, vol. 33, no. 1, pp. 2–13, Jan. 2007.

VI. THREDS TO VALIDITYIn Ex2, we selected only a single software system. Thissystem is relatively small, and each method included in
the system is not so long. Also, in the selected system,
most of repeated structures were repetition of simple caseentries and simple if-else-statements. Thus, we could notevaluate multiple statements folding and recursive folding.
If we apply the proposed preprocessing for more systems, we
can evaluate the folding operation for a variety of repeatedstructures.
Subjects in Ex2 have knowledge of software engineering, which probably has an impact on understandability ofsource code. If we conduct the same experiment for otherpeople (for example, people who hardly have experiences ofprogramming), we may obtain a different result.

[2] N. Nagappan, T. Ball, and A. Zeller, “Mining metrics to predict component failures,” in Proceedings of 28th International
Conference on Software Engineering., May 2006, pp. 452–
461.
[3] T. Hall, S. Beecham, D. Bowes, D. Gray, and S. Counsell, “A
systematic review of fault prediction performance in software
engineering,” IEEE Transactions on Software Engineering,
vol. PrePrints, no. 99, pp. 1–31, 2011.
[4] H. Hata, O. Mizuno, and T. Kikuno, “Bug prediction based
on ﬁne-grained module histories,” in Proceedings of 34th International Conference on Software Engineering., Jun. 2012,
pp. 200–210.
[5] Y. Kamei, S. Matsumoto, A. Monden, K. Matsumoto,B. Adams, and A. E. Hassan, “Revisiting common bug
prediction ﬁndings using effort-aware models,” in Proceedings of 26th IEEE International Conference on Software
Maintenance, Sep. 2010, pp. 1–10.

VII. CONCLUSION
This paper addressed that the presence of repeated structures have a negative impact on metrics measurement, andproposed a technique that remove repeated structures. The
proposed technique is used as a preprocessing of metrics
measurement from source code. We compared results of
metrics measurement with and without the proposed preprocessing on approximately 13,000 open source systems.
The comparison results showed that most of the target
methods included repeated structures and metrics values
were signiﬁcantly different between with and without the
preprocessing. Also, we investigated the relationship between subject’s understandability of target methods andtheir metrics values with and without the preprocessing.
We conﬁrmed that metrics values with the preprocessing
had stronger correlation with the understandability than ones
without the preprocessing.
In the future, we are going to this research as follows:• We tune the proposed technique. For example, notconsidering the difference of repeat count in each
repeated structure will have a signiﬁcant impact on
metrics measurement.
• By using the key idea that folding repeated structures,
we are going to develop a software tool for supporting
software development and maintenance. For example,
visualizing structures in a given method with the foldedfunctionality will help users to understand the method.

[6] R. Moser, W. Pedrycz, and G. Succi, “A comparative analysisof the efﬁciency of change metrics and static code attributes
for defect prediction,” in Proceedings of 30th International
Conference on Software Engineering, May 2008, pp. 181–
190.
[7] T. McCabe, “A complexity measure,” IEEE Transactions on
Software Engineering, vol. SE-2, no. 4, pp. 308–320, Dec.
1976.
[8] S. R. Chidamber and C. F. Kemerer, “A metrics suite forobject oriented design,” IEEE Transactions on Software Engineering, vol. 20, no. 6, pp. 476–493, Jun. 1994.
[9] V. Basili, L. Briand, and W. Melo, “A validation of objectoriented design metrics as quality indicators,” IEEE Transactions on Software Engineering, vol. 22, no. 10, pp. 751–761,
Oct. 1996.
[10] F. Simon, F. Steinbrückner, and C. Lewerentz, “Metrics based
refactoring,” in Proceedings of the Fifth European Conference
on Software Maintenance and Reengineering, Mar. 2001, pp.
30–38.
[11] M. Fowler, Refactoring: Improving the Design of Existing
Code. Addison-Wesley, 1999.
[12] E. Murphy-Hill, C. Parnin, and A. P. Black, “How we refactor,
and how we know it,” in Proceedings of the 31st International
Conference on Software Engineering, 2009, pp. 287–297.

ACKNOWLEDGMENT[13] A. Goldberg, “Programmer as reader,” IEEE Software, vol. 4,
no. 5, pp. 62–70, Sep. 1987.

This study has been supported by Grants-in-Aid for
Scientiﬁc Research (A) (21240002), Grant-in-Aid for Exploratory Research (23650014, 24650011), and Grand-inAid for Young Scientists (A) (24680002) from the Japan
Society for the Promotion of Science.

[14] S. Haiduc, J. Aponte, and A. Marcus, “Supporting program
comprehension with source code summarization,” in Proceedings of the 32nd ACM/IEEE International Conference on
Software Engineering - Volume 2, 2010, pp. 223–226.

126

[15] X. Wang, L. Pollock, and K. Vijay-Shanker, “Automatic
segmentation of method code into meaningful blocks to
improve readability,” in Proceedings of the 2011 18th Working
Conference on Reverse Engineering, 2011, pp. 35–44.
[16] R. P. L. Buse and W. R. Weimer, “Learning a metric forcode readability,” IEEE Trans. Softw. Eng, vol. 36, no. 4, pp.
546–558, Jul. 2010.
[17] A. Jbara, A. Matan, and D. G. Feitelson, “High-mcc functionsin the linux kernel,” in Proceedings of 34th International
Conference on Program Comprehension, Jun. 2012.
[18] J. J. Vinju and M. W. Godfrey, “What does control ﬂow reallylook like? eyeballing the cyclomatic complexity metric,” inProceedings of the 2012 IEEE 12th International Working
Conference on Source Code Analysis and Manipulation, 2012,
pp. 154–163.
[19] “pmccabe,”
http://http://manpages.ubuntu.com/manpages/
lucid/man1/pmccabe.1.html.
[20] Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue, “Method andimplementation for investigating code clones in a softwaresystem,” Information and Software Technology, vol. 49, no.
9–10, pp. 985–998, Sep. 2007.
[21] C. Lopes, S. Bajrachaya, J. Ossher, and P. Baldi, “Uci sourcecode data sets,” http://www.ics.uci.edu/∼lopes/datasets/.

127