Empirical Analysis of Change-Proneness in
Methods Having Local Variables with Long Names
and Comments
Hirohisa Aman

Sousuke Amasaki

Takashi Sasaki and Minoru Kawahara

Center for Information Technology
Ehime University
Matsuyama, Japan 790–8577
Email: aman@ehime-u.ac.jp

Faculty of Computer Scienceand Systems Engineering
Okayama Prefectural University
Soja, Japan 719–1197

Center for Information Technology
Ehime University
Matsuyama, Japan 790–8577

Abstract—This paper focuses on the local variable names andcomments that are major artifacts reflecting the programmer’s
preference. It conducts an empirical analysis on the usefulnessof those artifacts in assessing the software quality from theperspective of change-proneness in Java methods developed in
six popular open source software products. The empirical results
show: (1) a method having a longer named local variable ismore change-prone, and (2) the presence of comments inside themethod body strengthens the suspicions to be modified after the
release. The above artifacts are worthy to find methods which
can survive unscathed after the release.

I.

I NTRODUCTION

Programming is one of the most crucial activities insoftware development. While well-done upper processes, i.e.,
successful requirements analysis and system/module design are
required to develop high quality software products, the importance of those activities are based on proper programming(implementations). Since programming activities are usually
done by programmers, i.e., human beings, the product quality
can vary from person to person. That is to say, different
programmers may write different programs for the same specification: one programmer writes a simple and comprehensible
program, but another programmer writes a complicated program that is hard to understand. Thus, it would be significant tofocus on the factors reflecting the programmer’s preference forsuccessful quality management. We will look at two types ofartifacts on which programmers have considerable discretion—“comments” and “local variables.”Comments written in a program have no impact on the
program’s execution. It is at the programmer’s discretion
whether they write comments or not, and what they describe ascomments. However, comments do not seem to be independentof program quality: well-written comments have been said tobe related to “code smells” of problematic code fragments thatshould be refactored [1]. Although comments themselves do
not have harmful effects on the program, some programmers
write detailed comments to compensate for a lack of clearness
in their complicated code fragments. That is to say, comments
may be used as “deodorant” masking a code smell, and they
can be signs to detect parts of poor quality [2], [3], [4], [5].
Local variables declared in a method or a function are
also artifacts that the programmer would be able to decide

freely. Although names of other variables—arguments of amethod/function and global variables—are often controlled at
the preceding design phase, names of local variables would
be at the programmer’s discretion. There would be diversity
in naming—one programmer prefers short names such as iand c (single letter) or idx and cnt (abbreviated word),
but another programmer may like to use long and meaningful
names such as index and countOfCollisions (fully
spelled word). While a variable having a longer name canprovide richer information and can be easier to understand,long named variables may not be often required in a narrow
scope [6]. Some coding standards [7], [8] also say that local
variable names should (can) be shorter. If a programmer daredto use a long named local variable in a method/function, it
might be a sign that the programmer considered the codefragment was complicated. It may be yet another code smell—
this is the motivation of our research.
The contribution of this paper is to report the results ofour empirical analysis on the chances of modifications or bug
fixes occurred in methods having long named local variables
and comments. To the best of our knowledge, there has notbeen an empirical study on change-proneness (including faultproneness) by focusing on both comments and the lengths of
local variable names in the past.
The remainder of this paper is organized as follows. Section
II describes the related work. Section III presents an empiricalanalysis for six popular open source software products. Finally,
Section IV gives the conclusion and our future work.
II.

R ELATED W ORK

It has been widely known that comments are useful artifacts
to enhance the comprehensibility of programs [9], [10], [11].
However, comments are sometimes added to compensate fora lack of clearness in the program—such a program is hardto understand without its comments. Kernighan et al. statedthat you should rewrite your program if you wanted to add
detailed comments [6]. Fowler pointed out that well-writtencomments may be a deodorant for a code smell [1]. Whilecomments are harmless to programs, they may be signs ofproblematic code fragments. Aman et al. focused on thoserelationships between comments and problematic programs,
and conducted empirical analyses on the fault-proneness incommented programs [2], [3], [4], [5]. Their empirical results
showed that the presence of comments written inside methodbodies (they called “inner comments”) is correlated with thefault-proneness in the programs. Therefore, inner comments
may be useful clues of code fragments to be revised. Steidl etal. proposed a refactoring manner to extract the code fragments
having one-line comments as a new method [12].
Lawrie et al. conducted a survey on program comprehension by focusing on the difference in style of variable names:(1) single letters, (2) abbreviated words and (3) fully spelledwords such as (1) i, (2) idx and (3) index, respectively[13]. Their survey results showed that the comprehension levelof the programs were monotonically increased as the variablename got longer from (1) to (3), but there was no significant
difference between (2) abbreviated words and (3) fully spelledwords. Thus, it seems that a long named local variable is notalways needed, and similar things are also said in the GNU
coding standard [7] and Java Coding Style [8] as local variablenames should (can) be shorter. The survey results by Lawrie
et al. and the heuristics in the coding standards motivated ourempirical analysis presented in the following section.
III.

E MPIRICAL A NALYSISThis section presents our empirical analysis on changeproneness in Java methods by focusing on the presence of long
named local variables and comments. Since a method having
a problematic code fragment requires some modifications or
bug fixes after its first release, the change-proneness may be
a simple valuable measure for assessing the method’s quality
and maturity level.
A. Research Questions
To clarify our goal in this empirical analysis, we consider
the following two research questions (RQs).
RQ1: Is the presence of long named local variables related tochange-proneness?
This research question is to empirically examine the heuristics that shorter names are better for local variables. If theanswer to RQ1 is YES, the length of a local variable isconsidered to be a simple but useful metric for assessing
code quality.
RQ2: Does the presence of inner comments affect the answer
to RQ1?
While the previous work [2], [3], [4], [5] reported that thepresence of inner comments is related to fault-proneness inprograms, there has not been a study on the combinationof comments and local variables. The examination ofthis combination can clarify the effects of two factors,comments and local variables.
B. Datasets
We analyzed six popular Open Source Software (OSS)
products of different size and domain, shown in Table I—
Angry IP Scanner (IP-Scanner)1 , Eclipse Checkstyle Plugin (Checkstyle)2 , FreeMind3 , GNU ARM Eclipse Plug-ins
1 http://angryip.org/

Product
IP-Scanner
Checkstyle
FreeMind
ARM
Hibernate
SQuirreLTotal

OSS PRODUCTS ANALYZED IN THIS PAPER .

KLOC
16
21
72
266
528
397
1, 300

Data Collection Period
2006-07-19 — 2015-06-05
2003-05-05 — 2015-04-14
2011-02-06 — 2014-06-28
2013-09-11 — 2015-04-06
2007-06-29 — 2015-05-11
2001-06-01 — 2015-05-09

We conducted the following data collection scheme foreach OSS product at the end of May, 2015.
1) Make the latest list of methods.
Make a clone of the latest Git repository, and list the methods(including constructors) which appear in the source files. Abstract methods and methods for testing or demos are excluded
from our method list.
2) Track the changes of each method.
For each method, track the changes of source files including
the method, then check whether the method has been modified
or not. Specifically, (1) make a list of commitments involvedin the source file, (2) check out the different versions of thefile corresponding to consecutive commitments, (3) extract themethod body from each version of each source file, and (4)decide whether the method was modified or not by comparing
the content of two methods corresponding to consecutive
versions. We regard a modification as one for fixing a bug
if bug-fixing-related keywords or bug IDs appeared in thecommitment log [14]3) Measure metric values for the initial version of each method.
For the initial version of each method, measure Lines of Inner
Comments (LIC)—the number of comment lines in the methodbody— and the lengths of local variable names. Measure thelength of name from two different perspectives: the letter countand the word count. Our measurement of the word count isbased on the camel case which is normally used in Java,in which the word count is the number of lower-case letters
followed by an upper-case letter, plus one.
Table II shows the number of methods collected, the ratiosof one or more change occurrences, two or more change
occurrences, and bug fix occurrences in the methods of each
OSS product. While there are individual differences in thenumber of methods and the ratios of change or bug fix occurrences, we believe it is important to find a commonly-observed
tendency for such data with diversity. Tables III and IV showsummarized statistics of the lines of inner comments and thelength of local variable names, respectively. The majority ofmethods have no inner comments or no local variable. The
4 http://gnuarmeclipse.livius.net/blog/
5 http://hibernate.org/
7 http://sourceforge.net/

Page

DomainNetworking
Code analysis
Mind-mapping tool
Development support
Object/Relational mapping
Database client(ARM)4 , Hibernate ORM (Hibernate)5 and SQuirreL SQL
Client (SQuirreL)6 . They all ranked in the top 50 popularJava products at SourceForge.net7 , are developed in Java, andtheir source files are maintained with Git. The restrictionsof language and version control systems are from our datacollection tools8 .

6 http://www.squirrelsql.org/

2 http://eclipse-cs.sourceforge.net/
3 http://freemind.sourceforge.net/wiki/index.php/Main

TABLE I.

8 http://se.cite.ehime-u.ac.jp/tool/TABLE II.

N UMBER OF METHODS IN EACH PRODUCT AND THE
OCCURRENCES OF CHANGES AND BUG FIXES AT THOSE METHODS .

Product
IP-Scanner
Checkstyle
FreeMind
ARM
Hibernate
SQuirreL
Total#methods
1, 504
1, 5937, 4933, 72925, 023
22, 31961, 661

Occurrence (ratio)
One or more
Two or moretimes changes
times changes
27.3%
13.6%
30.6%
10.6%
35.1%
8.3%
39.6%
17.4%
27.3%
7.9%
16.1%
6.0%
25.0%
8.1%

Bug fix
4.3%
19.5%
31.0%
4.3%
15.5%
6.9%
13.4%

TABLE III.
R ATIO OF NON - COMMENTED METHODS AND
D ISTRIBUTION OF L INES OF I NNER C OMMENTS (LIC).
Product
IP-Scanner
Checkstyle
FreeMind
ARM
Hibernate
SQuirreL
Total

Ratio of
LIC = 0
77.2%
69.9%
83.2%
75.4%
88.9%
89.2%
86.7%

Q1 : 25 percentile;

Distribution of LIC except for LIC= 0
Min.
Q1
Q2
Q3
Max.
1
1
1
2
17
1
1
2
3
130
1
1
2
3
351
1
1
2
4
79
1
1
2
3
72
1
1
2
4
130
1
1
2
3
351
Q2 : median;

Q3 : 75 percentile

TABLE IV.
R ATIO OF METHODS HAVING NO LOCAL VARIABLE AND
D ISTRIBUTION OF LETTER COUNTS OF THE LONGEST- NAME LOCALVARIABLES .
Product
IP-Scanner
Checkstyle
FreeMind
ARM
Hibernate
SQuirreL
Total

Ratio ofno variable
72.2%
53.7%
68.6%
65.4%
77.3%
72.5%
73.1%

Q1 : 25 percentile;

Distribution of maximum letter counts
Min.
Q1
Q2
Q3
Max.
1
5
8
12
25
1
6
10
13
38
1
5
9
13
43
1
5
9
13
33
1
5
9
14
42
1
5
8
12
40
1
5
9
13
43
Q2 : median;

Q3 : 75 percentile

distribution of a variable name’s length is approximately thesame. Since the longest named variables in terms of “lettercount” were also the longest named ones in terms of “wordcount” in 96.6% of methods, we showed only “letter count”
data in the table; we will deal with the length of local variable
using the letter count in the following analysis.
C. Analysis for RQ1: Is the presence of long named local
variables related to change-proneness?
We compared the ratios of change occurrences and bug fix
occurrences among the categories of methods shown in Table
V. These categories are based on the length of the variable’s
name. Single letter or two-letter variables are considered tobe the category of methods which have only much shorter
variables (C1 ). Since three or more letters may form anabbreviated word or a full-spelled word, we regarded three(3)letters as a threshold between C1 and C2 . Nine(9) letters is themedian of all variable names (see Table IV), so we separated
C3 from C2 by setting nine as the upper limit of C2 .
Figure 1 shows the ratios of one or more change occurrences, two or more change occurrences, and bug fix
occurrences for each OSS product. There seem to be roughly
increasing tendencies for all ratios in all products. We identified that those increasing tendencies are statistically significant
through the Cochran-Armitage test [15] at a 0.01 significance

TABLE V.
category
C0
C1
C2
C3

M ETHOD CATEGORIES .

description
methods having no local variable
methods whose longest named local variable consists of
one or two letters
methods whose longest named local variable consists ofn letters, where 3 ≤ n ≤ 9methods whose longest named local variable consists ofmore than 9 letterslevel. Thus, it seems to be a common tendency that a method
having a longer named local variable is more change-prone.
Such a method has a low probability to survive unscathed, andit would require more costs to be improved after the release.
Since the larger method is more change-prone and more
fault-prone in general, there was a concern that the method
size (lines of code: LOC) might be a confounding factor in our
results. We computed Spearman’s rank-correlation coefficients
between LOC and the length of variable names for the methods
having local variables. The coefficient resulted in 0.352 forall data; for each OSS product, the coefficients were between
0.290 and 0.468. That is to say, there seem to be only weakcorrelations. Therefore, we can say the presence of long named
local variables is related to change-proneness.
D. Analysis for RQ2: Does the presence of inner comments
affect the answer to RQ1?
In order to examine the effects of inner comments withlong named local variables, we divided each category in RQ1
into two sub categories corresponding to commented methods
and non-commented methods. Figure 2 shows the differencesof ratios between commented methods and non-commented
methods: the horizontal axes correspond to categories C0 , C1 ,C2 and C3 , and the vertical axes signify the ratio of commented
methods minus the ratio of non-commented methods, respectively. All differences of ratios except for C2 in Checkstyle
are positive. That is to say, commented methods have higher
change ratios and higher bug fix ratios than non-commented
ones. Only the results of C2 in Checkstyle differed from theothers (see Fig.2(b)), and it also showed different tendencies in
RQ1 (see Fig.1(b)). Since the ratio of commented methods inCheckstyle are higher than the other OSS products (the lowest
ratio of LIC= 0 in Table III), the product might have a slightly
different commenting manner from the others.
Although the differences in ratios were not always statistically significant9 , we saw a tendency that commented methods
are more change-prone in most cases of the results, and thepresence of comments does not invalidate the results of RQ1.
Rather, the usefulness of the results in RQ1 can be enhanced
by focusing on the presence of comments.
From the empirical results, we suggest to practitioners thatthey conduct a review of their programs when they wanted
to declare local variables with longer names and to add innercomments; this can be yet another code smell.
9 We performed statistical tests on the differences in ratios for 12 pairs (4categories × 3 types of ratios). The following pairs showed significant differences at an 1% significance level: 3/12 in IP-Scanner, 2/12 in Checkstyle,
11/12 in FreeMind, 8/12 in ARM, 10/12 in Hibernate and 2/12 in SQuirreL.

Ratio

0.6

0.5
0.4
0.3
0.2
0.1
0.0

0.4
0.2
0.0
C0

C1

C2

C3

0.5
0.4
0.3
0.2
0.1
0.0
C0

(a) IP-ScannerFig. 1.

C1

C2

C3

0.5
0.4
0.3
0.2
0.1
0.0
C0

(b) Checkstyle

C1

C2

C3

0.5
0.4
0.3
0.2
0.1
0.0
C0

(c) FreeMind

C1

C2

C3

0.2
0.1
0.0
C0

(d) ARM

C1

C2

C3

0.2

Ratio

C1

C2

C3

(f) SQuirreL

Change ratios and bug fix ratios of methods in each OSS product.
0.10

0.2
0.1
0.0

0.1

0.2

0.3

0.0

0.0

0.0

0.10

−0.1

−0.2

0.00

0.00

−0.05

−0.3

−0.2

0.05

0.05

−0.1

−0.05

−0.10

−0.2

C0 C1 C2 C3(a) IP-ScannerFig. 2.

C0(e) Hibernate−0.10

C0 C1 C2 C3

C0 C1 C2 C3

C0 C1 C2 C3(b) Checkstyle(c) FreeMind(d) ARM

C0 C1 C2 C3

C0 C1 C2 C3(e) Hibernate(f) SQuirreL

Differences in change ratio and bug fix ratio between commented methods and non-commented methods.

E. Threats to Validity
In general, there is diversity in programmer’s preference, sosome programmers prefer to write detailed comments and/or
to use longer named local variables. Therefore, the notion ofownership [16] of methods may affect the results in this paper.
Since our data did not show large variances among products(see Tables III and IV), the diversity in the programmer’s
preference does not seem to have an impact on the results.
Since our data collection focused only on the occurrencesof modifications (including bug fixes), we missed the size ofmodifications. This causes a concern that we might overestimate the contribution of many minor changes. However, thefact remains that those methods require some changes after
their release, so our results do not become worthless.
IV.

C ONCLUSION

We have empirically examined the heuristics that name of
local variables should be shorter, in terms of change-pronenessin Java methods. As the results, we obtained the following two
findings: a method having a longer named local variable ismore change-prone, and the presence of comments inside themethod body strengthens the suspicions to be modified after
the release. Our future work includes: (1) a further analysis
with varying combination of the variable name’s length andthe presence of inner comments, (2) analyses on other large
scale products written in languages other than Java, (3) ananalysis of the effects of ownership on change-proneness, (4)an empirical study on the impact of a variable’s scope length
and/or its type, and (5) a semantic analysis of variables’ names.
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #25330083.
R EFERENCES[1] M. Fowler, Refactoring: Improving the Design of Existing Code.
Boston, MA: Addison-Wesley Longman, 1999.

[2] H. Aman, “An empirical analysis on fault-proneness of well-commented
modules,” in Proc. 4th Int’l Workshop Empir. Softw. Eng. in Practice,
Oct. 2012, pp. 3–9.
[3] ——, “An empirical analysis of the impact of comment statements on
fault-proneness of small-size module,” in Proc. 19th Asia-Pacific Softw.
Eng. Conf., Dec. 2012, pp. 362–367.
[4] H. Aman, S. Amasaki, T. Sasaki, and M. Kawahara, “Empirical analysis
of comments and fault-proneness in methods: can comments point
to faulty methods?” in Proc. 8th Int’l Symp. Empir. Softw. Eng. andMeasurement, Sept. 2014, p. 63.
[5] ——, “Empirical analysis of fault-proneness in methods by focusing
on their comment lines,” in Proc. 21st Asia-Pacific Softw. Eng. Conf.,
vol. 2, Dec. 2014, pp. 51–56.
[6] B. W. Kernighan and R. Pike, The practice of programming. Boston,
MA: Addison-Wesley Longman, 1999.
[7] Free Software Foundation, “Gnu coding standards,”
https://www.gnu.org/prep/standards/.
[8] Sun Microsystems, “Code conventions for the java programming language,” http://www.oracle.com/technetwork/java/codeconvtoc136057.html.
[9] M. J. Sousa and H. Moreira, “A survey on the software maintenanceprocess,” in Proc. Int’l Conf. Softw. Maintenance, Nov. 1998, pp. 265–274.
[10] T. Tenny, “Program readability: Procedures versus comments,” IEEE
Trans. Softw. Eng., vol. 14, no. 9, pp. 1271–1279, Sept. 1988.
[11] S. N. Woodfield, H. E. Dunsmore, and V. Y. Shen, “The effect ofmodularization and comments on program comprehension,” in Proc.
5th Int’l Conf. Softw. Eng., Mar. 1981, pp. 215–223.
[12] D. Steidl, B. Hummel, and E. Juergens, “Quality analysis of sourcecode comments,” in Proc. 21st Int’l Conf. Program Comprehension,
May 2013, pp. 83–92.
[13] D. Lawrie, C. Morrell, H. Feild, and D. Binkley, “What’s in a name? astudy of identifiers,” in Proc. 14th Int’l Conf. Program Comprehension,
June 2006, pp. 3–12.
[14] J. Śliwerski, T. Zimmermann, and A. Zeller, “When do changes induce
fixes?” in Proc. Int’l Workshop on Mining Softw. Repositories, May
2005, pp. 1–5.
[15] A. Agresti, Categorical Data Analysis, 2nd ed. N.J.: Wiley, 2002.
[16] D. Posnett, R. D’Souza, P. Devanbu, and V. Filkov, “Dual ecologicalmeasures of focus in software development,” in Proc. 35th Int’l Conf.
Softw. Eng., May 2013, pp. 452–461.