Empirical Study of Abnormalities in Local
Variables of Change-Prone Java Methods
Hirohisa Aman

Sousuke Amasaki
Tomoyuki Yokogawa

Minoru Kawahara

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

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

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

Abstract—The naming of local variables is usually at the
programmer’s discretion. Thus, there is a diversity in naming
local variables and this may cause variations in the code quality.
Many coding conventions say that the name of a local variable
can/should be short. This paper focuses on such conventions, andaims to explore the trends of local variables’ names in Java andexamine if abnormal local variables create harmful effects on
the code quality. This paper collected data on local variables—names, scopes and types—from six popular open source products,
and proposes to evaluate their abnormalities by using the notionof the Mahalanobis distance. The empirical results report thefollowing findings: 1) The trend of naming local variables differs
according to the variable type; 2) The majority of local variables
have short names with narrow scopes, where a name is often aword or its abbreviated form; 3) Methods having abnormal local
variables are about 1.2 – 2.5 times more likely to be change-prone
than the others. While the naming of local variables depends on
who writes the code, there seem to be common trend of naming.
Java methods with deviant local variables tend to be fixed manytimes after their release and cannot survive unscathed.

I. I NTRODUCTION
Programmers use variables to store values or refer toobjects in their programs. In most procedural or objectoriented languages, variables are classified into two groups:
global variables and local variables. While global variables
are available everywhere in a program, local ones can be used
only within a method (function) or a narrower block. Since themanipulation of a global variable has a risk of causing side
effects in other parts of the program, it is better to use local
variables instead of global ones to prevent fault creation [1].
Programmers can freely decide the names of local variables
in many cases because of their localized scopes. Thus, thenaming of local variables can vary considerably from person
to person. Such a diversity in naming local variables may cause
a variation in the code readability and understandability. Many
coding conventions and practices give common recommendations in regard to the naming of local variables: names of local
variables can/should be short (e.g., [1], [2], [3]). Needless tosay, a longer and more descriptive name for a local variable
would make it easier to understand its role. However, Lawrie
et al. [4] empirically showed that the comprehensibility ofcode does not significantly differ between a fully-spelled nameand its abbreviated form (e.g., index vs. idx). Binkley etal. [5] focused on the human short-term memory and showedthat a long identifier name degrades the readability of code.
Kernighan et al. [1] said that it is overdone to give a long anddescriptive name to a local variable with a narrow scope. Basedon these various reports and recommendations, we have thefollowing simple questions which are our motivations: “Whatare the real trends of local variables’ names and scopes?” and“Is an abnormal variable harmful to the quality of code?.”In this paper, we conduct an empirical analysis on local
variables collected from open source software (OSS) products
written in Java, and report the trends of local variables andthe impact of abnormal variables on the quality of code fromthe perspective of the code change-proneness. The key contributions of this paper are as follows: 1) reports of empirical
data in regard to local variables’ names, scopes and types; 2)
an application of the concept of the Mahalanobis distance tothe abnormality evaluation of local variables; 3) reports on therelationship between the presence of an abnormal variable ina Java method and the method’s change-proneness.
The remainder of this paper is organized as follows: Section
II describes properties of local variables. Section III presents
preferred features of local variables and our research questions(RQs), then defines the abnormality of local variables to tackle
our RQs in a quantitative way. Section IV reports the resultsof data analyses on six popular OSS products, and gives
discussions on them. Section V briefly describes related work.
Finally, Section VI presents our conclusions and future work.
II. P ROPERTIES OF L OCAL VARIABLES
In preparation for our analysis of local variables, we briefly
describe major properties of local variables in this section.
Notice that our descriptions are aimed at Java programs.
A. NameAny local variable has its own name. Giving a nameto a local variable is almost always at the programmer’s
discretion. That is to say, requirement specifications and design
documents usually do not specify names of local variables,
so programmers can give any names to their local variables

during their programming activities. Hence, the naming of
local variables is affected by the programmer’s preferenceor custom in many cases. For a local variable, different
programmers may want to give different names. The namesof local variables are the major properties which can vary
according to the programmer. The names of local variables
are classified into the following two categories: 1) A single
alphabetical character; 2) An alphabetical character followed
by one or more alphanumeric character(s), where the underscore character (“_”) is also included in the set of alphabeticalcharacters.
A name according to category 1) is often the initial characterof the word which expresses the role. Category 2) can bedivided into subcategories: 2a) A fully-spelled word; 2b) An
abbreviated word; 2c) A composition of two or more words;2d) Another string.
For example of an index of an array, “i” is often used fora variable in category 1); names corresponding to 2a) and 2b)
can be “index” and “idx,” respectively. For 2c), compound
names may be “indexOfArray.” In Java, a compound nameis usually made in the style of camel case. In camel case, eachword or abbreviation begins with a capital letter except for the
first word (abbreviation), e.g., “indexOfArray.” Although
we can also give a name in which all words (abbreviations) begin with capital letters like “IndexOfArray,” it is a common
practice to begin a name of local variable with a lower-casecharacter; the former camel case and the latter one are called“lower camel case” and “upper camel case,” respectively. In
snake case, words or abbreviations are concatenated with theunderscore character, e.g., “index_of_array.” The (lower)
camel case is the most popular style in Java; the snake casetends to be widely used in C/C++.
A name according to 2a), 2b) or 2c) is more descriptive thanthe ones of category 1). Thus, such names of local variables
tend to make it easier to understand the role [4]. On the other
hand, a name corresponding to 2d) might be hard to understandby others—the author is possibly the only person who canunderstand it. That might require comments or an external
document.
B. Scope
A local variable is valid within a certain range of sourcecode lines, which is referred to as its “scope.” When a local
variable is declared in a block, the variable’s scope ranges
from its declaration line to the end of the block.
In general, a narrower scope is better for a local variable.
A local variable with a wider scope is likely to be involved in
more executable statements, and it would make more complex
data dependencies. Consequently, local variables having wide
scopes may cause the poor readability of program which isone of the major features observed in fault-prone programs.
A local variable’s scope can relate to the variable’s name.
When a variable has a narrow scope, there is no need tocarefully explain the role of the variable because of its limited
range. That is to say, we do not have to give a descriptive nameto the variable in order to express what its task is. For example,“i” would be acceptable as the name of the local variablewhich is the index of the array in a small “for” loop; while“indexOfArray” makes it easier to understand its role, it
may be overdone [1]. If the loop has a long and complicatedblock, it might be better to give a more descriptive name.
C. Type
Types of local variables in Java are categorized into twogroups: 1) primitive types and 2) reference types [6]. The
primitive types are fundamental data types predefined in theJava language specification: Boolean value, integer and floating point number. The reference types include the class types,
the interface types and the array types: a class type variable
is a reference to an instance of the class; an interface typevariable is a reference to an object which has the interface; anarray variable is a reference to an array of variables.
The type of a local variable may have an affect on the naming of the variable. For example, class types Connectionand Statement usually appear in database related programs,
and names of corresponding local variables are often con andstmt, respectively. When a local variable is an array, some
programmers give a name in a plural form (e.g., values) ora name emphasizing that it is an array (e.g., valueArray).
III. A BNORMALITY OF L OCAL VARIABLES
A. Preferred Features and Research Questions
From the perspective of coding standards/conventions andprogramming practices, the following two principles have been
preferred for local variables.
1) Short name: Kernighan and Pike [1], the Sun Java code
convention [2] and the GNU coding standard [3] say that
local variable names can/should be short.
2) Narrow scope: The GNU coding standard [3] and theGoogle Java style [7] say that local variables should be
declared at the points which minimize their scopes.
Boswell et al. [8] also proposed giving a short name to a
local variable if its scope is narrow, and a longer and more
descriptive name to it if its scope is wide. Their proposal seems
to be consistent with the above two principles.
As mentioned above, we have questions about the real trendsof local variables and the relationship between the abnormalityof local variables in a Java method and the method’s changeproneness. Thus, we tackle the following RQs in this paper:
RQ1: What are the real trends of local variables in terms of
their properties? (What are abnormal ones?)
RQ2: Is the presence of an abnormal local variable in a Javamethod related to the method’s change-proneness?
RQ1 is a basic question. By collecting a lot of local variables
and analyzing their properties, we will be able to see the defacto standard for local variables and the relationships withthe preferred features of local variables. Needless to say, it
is natural that there are diversities in the properties of local
variables. While considering such diversities, we will explore
abnormal local variables in the real data and report the results.

RQ2 is an application of our abnormality evaluation for
local variables: how can our empirical study contribute to
the software engineering community? If the presence of anabnormal local variable in a method is harmful to the qualityof code, the method cannot survive unscathed after its release.
We will focus on the change-proneness of methods as ourquality criterion in this paper.
B. Degree of Abnormality
In order to perform our data analysis on the above RQs, wehave to quantify the abnormality of a local variable. We define
the abnormality of local variables in the rest of this section:
1) Classify local variables into several categories according
to their types (Sect. III-B1).
2) For each local variable in each category, represent thevariable as the feature vector (𝒙) whose elements correspond to the variable’s name and scope (Sect. III-B2).
3) For each category, compute the mean vector of feature
vectors (𝝁) and the variance-covariance matrix (𝑆), thenuse the Mahalanobis distance between 𝒙 and 𝝁 as
the abnormality of a local variable corresponding to 𝒙
(Sect. III-B3).
1) Classification of Local Variables: Types of local variables may be related to the naming of those variables. In order
to avoid an impact caused by the difference in variable types,
we will classify local variables into categories according totheir types. In this paper, we distinguish between a primitive
type and a reference type because a reference type variable canhave richer information than a primitive type one. Moreover,
we discriminate between an array and a single variable sincean array is a set of variables1 . Now we will exclude thereference types used for handling exceptions (or errors)2 fromour dataset since those exception variables are usually used
only in exception handling blocks and often automaticallygenerated by an integrated development environment such as
Eclipse. Hence, we consider the following four categories oftype: (i) primitive type, (ii) primitive array, (iii) reference typeand (iv) reference array.
2) Feature Vector of a Local Variable: For each local
variable in each category mentioned above, we consider acolumn vector 𝒙 = (𝑥1 , 𝑥2 , 𝑥3 )𝑇 , where 𝑥1 , 𝑥2 and 𝑥3 are
the number of characters comprising the variable’s name, thenumber of words comprising the name, and the number oflines where the variable is available, respectively3 . We willcall 𝒙 the “feature vector” of the local variable in this paper.
The first element—𝑥1 : the number of characters comprising
the local variable’s name—represents the length of the namein character count. A long name possibly has an affect on
the readability of the code [5]. The second element—𝑥2 :the number of words comprising the name—is related to the
1 According to the Java language specification, an array is also of a reference
type. However, we will not include arrays in our definition of reference typesince we distinguish between an array and a single variable.
2 We regard a class or interface type whose ancestor is Exception, Erroror Throwable as an exception type.
3 Symbol 𝑇 signifies the transpose of a vector.

amount of information which the name presents. A name withmore words tends to be more descriptive. In this paper, we
count the number of words in accordance with the camel
case or the snake case. The third element—𝑥3 : the numberof lines in which the variable is valid—gives the length ofscope. Popular coding conventions say that the scope of a
local variable should be minimized [3], [7]. Moreover, thescope of a local variable may be related to the variable’s
name: for example, a programmer may dare to give a longand descriptive name to a local variable which has a wide
scope.
3) Mahalanobis Distance: Let 𝝁 = (𝜇1 , 𝜇2 , 𝜇3 )𝑇 be themean vector of feature vectors in a type category. Given thefeature vector 𝒙 of a local variable, the distance between 𝒙 and𝝁 can be the degree of abnormality which the variable has.
In many cases, we see the Euclidean distance as a distance
between two vectors (points), which is computed with:√(𝒙 − 𝝁)𝑇 (𝒙 − 𝝁) .
∣𝒙 − 𝝁∣ =However, the Euclidean distance does not consider the dispersion of data and the correlations between their elements.
Hence, we will use the Mahalanobis distance instead of the
Euclidean distance. The Mahalanobis distance is a useful
notion of distance to detect abnormal data while considering
the distribution of data [9]. The rest of this subsection presents
a brief explanation of the Mahalanobis distance.
The Mahalanobis distance between 𝒙 and 𝝁, 𝑑(𝒙, 𝝁), is
computed with the following equation:√(𝒙 − 𝝁)𝑇 𝑆 −1 (𝒙 − 𝝁) ,(1)𝑑(𝒙, 𝝁) =where 𝑆 = ( 𝜎𝑖𝑗 ) is the variance-covariance matrix (for 𝑖, 𝑗 =1, 2, 3) and 𝑆 −1 is its inverse matrix; 𝜎𝑖𝑖 is the variance of
the 𝑖-th element, and 𝜎𝑖𝑗 is the covariance between the 𝑖-th
element and the 𝑗-th one (for 𝑖, 𝑗 = 1, 2, 3).
To give an intuitive interpretation of the Mahalanobis distance, let us consider the case of a one-dimensional vector,
i.e., the case of scalar: 𝒙 = 𝑥 and 𝝁 = 𝜇. In this case, theMahalanobis distance is computed with:√1∣𝑥 − 𝜇∣.
(2)(𝑥 − 𝜇) 2 (𝑥 − 𝜇) =𝑑(𝑥, 𝜇) =𝜎𝜎That is to say, the Mahalanobis distance is the Euclidean
distance (∣𝑥 − 𝜇∣) normalized by the standard deviation (𝜎)of data. Equation (1) is the generalized form for a multidimensional vector.
By using the Mahalanobis distance, we can evaluate theabnormality of our object while considering their data distribution and correlations.
IV. E MPIRICAL S TUDY
A. Aim and Dataset
The aims of this study are to report the results of empiricalanalyses in regard to local variables and to discuss the results.

TABLE IS URVEYED OSS PRODUCTS .
product
Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJavatotal

size (KLOC)
635
124
253
645
431
230
2, 048domainsearch engine
JSON parser/generator
set of common libraries
game-development application framework
distributed SQL query engine
reactive extensions for JVM

We explore six OSS products4 shown in Table I. The key
reasons why we used them are:1) Their source files have been maintained with Git.
Since this study requires a fine-grained source code analysis which explores local variables and code changes inmethods, Git is suitable for our empirical study: Git allows
us to make a clone of the repository on our local disk andprovides powerful functionalities for analyzing source codeand their changes.
2) Their source programs are written in Java.
This reason comes from the limitations of the datacollection tools we developed: JavaMethodExtractor and
JavaVariableScopeExtractor5 .
3) They are popular and large-scale products.
In general, it is hard to assure a generality of empiricalresults if they are obtained from minor or small-scale
products, and those results would be less attractive forpractitioners and researchers. Hence, we collected datafrom large-scale products that are as popular as possible:
each of the above six products has source programs whose
total size is larger than 100 KLOC, and is ranked in the
top 30 products which have more “stars” at GitHub.
B. Procedures
We collect data of each product in the following procedure:
1) For each Java file, examine all code changes that occurredin the file through commits on the repository.
2) For each version of each Java file, make lists of methods6
declared in the file by using our tool, JavaMethodExtractor.
3) For each method appearing at each version of each Java file,
check if there was a change from the previous version: extract the code fragments corresponding to both the method
and its previous version, and compare those fragments.
4) For each modified version of each method, extract all local
variables by using our tool, JavaVariableScopeExtractor,
and record their names, scopes and types.
Through the above four steps, we obtain the change historyof each Java method and their local variable data. Then weanalyze the data of each product with the following procedure:
1) Classify the set of local variables into four subsets according to the type categories (i)–(iv) defined in Sect. III-B1.
4 https://github.com/{elastic/elasticsearch, alibaba/fastjson, google/guava,
libgdx/libgdx, prestodb/presto, ReactiveX/RxJava}
5 http://se.cite.ehime-u.ac.jp/tool/
6 Constructors are included, but abstract methods are not included.

TABLE IIN UMBER OF METHODS APPEARING IN THE LATEST VERSION OF
SURVEYED OSS PRODUCTS .
product
Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJavaTotal#methods having
no variable one or more variables
20, 2034, 347
1, 163
1, 01016, 064
5, 43928, 283
7, 22317, 146
4, 23610, 983
2, 76193, 84225, 016

total
24, 550
2, 17321, 50335, 50621, 382
13, 744
118, 858

2) For each local variable in each subset, make the corresponding feature vector.
3) For each type category, compute the mean vector in thecorresponding subset of feature vectors. If the distributionof metric values is skewed, perform a log transformationon the values before computing the mean vector.
4) For each local variable (each feature vector), computethe Mahalanobis distance from the mean vector of thecorresponding type category: the Mahalanobis distance isthe abnormality of the corresponding local variable.
5) Categorize methods into three groups: 𝑀0 , 𝑀1 and 𝑀2 .
𝑀0 is the set of methods having only low-level abnormal
local variable(s); 𝑀2 is the set of methods having a highlevel abnormal local variable; 𝑀1 is the set of othermethods. Then, compare those three sets of methods interms of the rates of change-prone methods; we consider amethod whose change count is greater the third quantile(75% percentile) of all methods to be a change-prone
method.
C. Results
As a result of our data collection, 118, 858 methods were
found in the surveyed products (see Table II). Since we areconducting an analysis focusing on local variables, our dataset
consists of 25, 016 methods which have a local variable.
1) Names Given to Local Variables:
For all products, the following trends were commonly observed: 1) the majority of local variables are of primitive or reference types; 2) arrays are the minority. Table III summarizes
the frequently-appearing names of local variables ranked in
the top 10 of declaration count7 for each type category, where
7 When two or more variables with the same name but different scopes
appeared in a method, we counted them independently.

TABLE IIIF REQUENTLY APPEARING NAMES .
type(i) primitive(ii) primitive
array(iii) reference(iv) reference
arrayvariable names (#products)
i (6), index (5), size (4), result (3),value (3), count (2), offset (2),length (2), len (2), j (2), c (2), n (2)bytes (5), chars (4), array (3), values (2),buf (2), buffer (2), data (2), indexes (2)value (6), builder (3), entry (3),other (2), field (2), result (2), that (2)array (3), files (3), values (2), items (2),result (2), fields (2), parameters (2)TABLE IV
D ISTRIBUTIONS OF CHARACTER COUNTS , WORD COUNTS AND SCOPE OF LOCAL VARIABLE .
(a) character counts of local variable nameproduct
min
25%
50%
75%
max
(i) primitive
Elasticsearch
1
3
6
10
35
Fastjson
1
2
5
7
30
Guava
1
1
4
8
30
libGDX
1
1
4
7
27
Presto1
4
7
1032
RxJava1
12523(ii) primitive array
Elasticsearch
1
4
5
10
19
Fastjson
1
4
5
7
26
Guava
1
5
5
7
22
libGDX15
6
820
Presto2
6
9
13
20
RxJava—————(iii) reference
Elasticsearch
1
5
7
11
33
Fastjson
1
5
7
10
30
Guava
1
5
7
9
30
libGDX1
4
6
824
Presto1
5
8
1240
RxJava1
13
531(iv) reference array
Elasticsearch
1
5
7
10
22
Fastjson
1
5
7
12
21
Guava
1
5
6
10
21
libGDX15
7
921
Presto4
6
9
12
24
RxJava1
1
1
516(b) word counts of local variable namemin 25%50%75%
max(i) primitive
1
1
1
2
8
1
1
1
2
5
1
1
1
2
7
1
1
1
2
6
1
1
1
2
5
1
1
1
1
4
(ii) primitive array
1
1
1
1
3
1
1
1
1
4
1
1
1
1
5
1
1
1
2
3
1
1
2
2
4
—
—
—
—
—
(iii) reference
1
1
1
2
7
1
1
1
2
5
1
1
1
2
5
1
1
1
2
5
1
1
1
2
6
1
1
1
1
5
(iv) reference array
1
1
1
2
3
1
1
1
2
4
1
1
1
2
4
1
1
1
2
5
1
1
1
2
4
1
1
1
1
2

the number in parentheses signifies the number of products inwhich the name is ranked in the top 10. For example, name iof category (i) is a frequently-appearing name common to all
six products; name builder of category (iii) is a frequently
appearing name in three out of the six products.
From Table III, we can see that different type categories
have different tendencies in their popular names. While namesof (i) primitive type are the ones representing scalar quantities,
names of (iii) reference type tend to be the ones having richer
meanings. For both array types (ii) and (iv), the plural formof a word (e.g., values) or array is often used as thename of a local variable. While single-character names also
appear in category (i), the majority of the names are single
English words or their abbreviated forms. As these results
show, popular names are short regardless of their type.
2) Distribution of Local Variables’ Features:
Table IV shows the distributions of the above three properties of local variables. In the table, the medians are shown inboldface to ease capturing their trends. The results of category(ii) in RxJava are omitted due to the small number of samples.
At first, we see Table IV(a) showing the character count ofvariable’s name. For category (i), while there are more singlecharacter names than other type categories, the majority ofcharacter counts are around 2–7. For the remaining categories,
the majority of lengths are around 5–9. That is to say, namesin these categories tend to be longer than category (i).
Secondly, we focus on the word counts (Table IV(b)). Most
results are common to all categories: the majority of names are
single-word ones. However, there are compound names using(c) scope of local variable
25%
50%
75%
max
(i) primitive
2
5
9
22
354
2
9
22
47
422
1
4
6
11
80
1
4
10
26
479
2
4
8
15
142
2
9
19
39
181
(ii) primitive array
2
4
6
10
59
2
3
8
31
167
2
5
7
15
56
2
5
10
21
478
2
4
8
17.5
74
—
—
—
—
—
(iii) reference
2
4
9
23
356
1
5
12
36
424
1
3
6
11
135
1
4
9
23
475
2
3
7
16
161
2
5
11
26
236
(iv) reference array
2
6
14
25
85
2
8
20
34
405
2
4.5
8
14
114
2
5
10
18
212
2
6
8
17.5
76
2
6
12
21
239

min

two or more words in more than 25% of the variables. The
difference of type category has less impact on the word count.
Next, we look at variables’ scopes (Table IV(c)). Among
all type categories, there are not so large differences in scope:most results are between a few lines and about 20 lines. The
results may depend on the method’s size.
Furthermore, we examined the Spearman rank-correlation
coefficients among the above three properties as well. Table
V shows the Spearman rank-correlation coefficients, where thestrong correlations (> 0.6) are shown in boldface. In the table,
strong positive correlations appear only in pairs of charactercount and word count. That is to say, there does not seem tobe a tendency for programmers to give longer names to local
variables having wider scopes in the real programs.
The above results showed that the majority of local variables
have non-compound short names comprising of a few or lesscharacters, with narrow scopes shorter than about 20 lines.
Such features seem to match with the preferred features of
local variables mentioned in many coding conventions.
3) Local Variables’ Abnormalities vs. Change-Proneness of
Methods:
We quantified local variables’ abnormalities by the Mahalanobis distance. To examine the impact of the abnormality on
quality of code, we classified the methods into the following
three groups and compared their rates of change-prone methods: 𝑀0 = { 𝑚 ∣ ma(𝑚) < 1 }; 𝑀1 = { 𝑚 ∣ 1 ≤ ma(𝑚) <2 }; 𝑀2 = { 𝑚 ∣ ma(𝑚) ≥ 2 }, where 𝑚 is a method andma(𝑚) is the maximum abnormality of local variable(s) in 𝑚.
Originally, we considered two types of metrics: the maximum

Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJavaof abnormalities in a method and the total of abnormalities ina method. The maximum type focuses on the most abnormal
variable. That is to say, our main focus is on the presenceof abnormal variable. On the other hand, the total type takes
into account abnormalities of all variables, so it seems to be
an overall evaluation of abnormalities within a method. Whileboth types of metrics have valid points, we also considered
the influence by the method size, i.e., the question if LOC is a
confounding factor. This is because it is generally true that alarger method is more change-prone. Thus, we examined theSpearman rank correlation coefficients between methods’ LOC
values and metric values of both two types. Table VI shows
the results. In consequence, we adopted only the “maximum”
type because the “total” type seems to be correlated with LOC.
Figure 1 shows the scatter diagram of the number of methodchanges and those methods’ abnormalities (𝑚𝑎 values). In
the figure, the horizontal red line expresses the threshold
which discriminates the change-prone methods correspond-

TABLE VI
C ORRELATION COEFFICIENTS IN PAIRS : LOC VS . THE MAXIMUMABNORMALITY AND LOC VS . THE TOTAL ABNORMALITY.
product
Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJavacorrelation coefficient
max
total
0.206
0.555
0.331
0.721
0.224
0.499
0.082
0.581
0.137
0.438
0.038
0.471

60
50
40
30
20
0

8

0

2

4

6

8

6

8

6

8

40
30
20
10
0

2

4

6

8

10

12

Number of method changes

14

50

ma

Fastjson

0

2

4

6

8

0

2

4

ma

ma

Guava

libGDX

12
10
8
6
4

30

Number of method changes

35

14

0

2

Number of method changes

10

Number of method changes

25
20
15
10
5

Number of method changes

0

6

0

0.039
−0.031
0.256
0.047−0.229
0.124

4

ma

Elasticsearch

25

0.094
0.155
0.124
0.184
0.147
−0.112

2

20

0.158
0.474
0.234
0.040
0.103
—

0

15

Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJava

0.205
0.166
0.294
0.068
0.131
0.063

10

Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJavaword vs. scope

5

Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJavachar. vs. word
char. vs. scope(i) primitive
0.814
0.276
0.720
0.268
0.745
0.392
0.667
0.229
0.833
0.147
0.464
0.257
(ii) primitive array
0.705
0.171
0.483
0.134
0.690
0.199
0.680
0.208
0.813
0.272
—
—
(iii) reference
0.814
0.098
0.785
0.140
0.713
0.128
0.575
0.012
0.836
0.127
0.427
0.077
(iv) reference array
0.768
0.164
0.839
0.095
0.778
0.251
0.675
0.082
0.863
−0.0820.303
0.275

Number of method changes

product

0

TABLE VC ORRELATIONS AMONG FEATURES .

0

2

4

6

8

0

2

4

ma

ma

PrestoRxJavaFig. 1. Scatter diagram of the number of method changes vs. 𝑚𝑎(⋅).

Fig. 2. Six partitions in Fig. 1.

ing to frequently-changed ones (whose change counts are
greater than the third quantile); the vertical blue lines signify
𝑚𝑎(𝑚) = 1 and 𝑚𝑎(𝑚) = 2, respectively. That is to say,the scatter diagram is divided into six partitions 𝐻𝑖 , 𝐿𝑖 (for𝑖 = 0, 1, 2) as shown in Fig. 2. The methods plotted in either
𝐻0 , 𝐻1 or 𝐻2 are defined to be change-prone methods. From
Fig. 1, we can see that more change-prone methods are in 𝐻1
or 𝐻2 than 𝐻0 . In other words, more change-prone methods
are included in sets 𝑀1 and 𝑀2 than 𝑀0 , and those methods
tend to have abnormal local variables.
Since the total numbers of methods in 𝑀0 , 𝑀1 and 𝑀2 differ each other, we examine the rates of change-prone methods
in these three sets to compare their change-proneness. Table
VII presents their rates which correspond to “(the number ofmethods plotted in 𝐻𝑖 ) / (the number of methods plotted in
𝐻𝑖 or 𝐿𝑖 )” (for 𝑖 = 0, 1, 2). For all products, 𝑀2 shows thehighest rate of change-prone methods. In other words, thepresence of an abnormal variable in a method is related tothe method’s change-proneness. The change-prone rate in 𝑀2
is 1.2 – 2.5 times higher8 than that in 𝑀0 which is the set of
8 Elasticsearch: 0.218/0.122 ≃ 1.8, Fastjson: 0.262/0.104 ≃ 2.5, Guava:
0.219/0.153 ≃ 1.4, libGDX: 0.229/0.191 ≃ 1.2, Presto: 0.252/0.175 ≃
1.4, RxJava: 0.240/0.123 ≃ 2.0.

TABLE VII
R ATES OF CHANGE - PRONE METHODS .
product
Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJava𝑀0( 49 )
12.2% 401
( 7 )10.4% 67
( 78 )
15.3% 509)(
19.1% 121
)
( 635
63
17.5% 361
( 29 )
12.3% 235

𝑀1
( 436 )
16.7% 2606
( 94 )
19.4% 485
( 471 )
13.6% 3473
( 661 )
14.6% 4519
( 485 )
18.8% 2585
( 330 )
17.5% 1888

𝑀2
( 297 )
21.8% 1360()
26.2% 124
( 474
)
351
21.9% 1601
( 453 )
22.9% 1975
( 340 )
25.2% 1347()
24.0% 164
682

TABLE VIIIR ESULTS OF STATISTICAL TESTS EXAMINING DIFFERENCES IN THE RATESOF CHANGE - PRONE METHODS BETWEEN 𝑀0 AND 𝑀2 .
product
Elasticsearch
Fastjson
Guava
libGDX
PrestoRxJava

𝜒2
17.55
7.06
9.98
4.00
9.16
13.72

𝑑𝑓
1
1
1
1
1
1

𝑝-value
0.00003
0.00790.00150.04560.00250.0002

power of test
0.995
0.889
0.917
0.552
0.896
0.982

methods having only normal variable(s). For each product, we
checked that the differences in rates between 𝑀0 and 𝑀2 using
the 𝜒2 test, and all products showed statistically significant
differences at 𝛼 = 0.05 (see Table VIII). While libGDX showsa smaller difference (19.1% vs. 22.9%) and a lower power oftest (0.552), the remaining five products are tested with highpowers of test (> 0.8), so the trend that “𝑀0 < 𝑀2 in termsof change-proneness” seems to be supported.
However, the products do not always show monotonicallyincreasing trends in the rates of change-prone methods. Thus,
we cannot say that the evaluation of abnormality, 𝑚𝑎(𝑚), hasa strong correlation with the change-proneness of method 𝑚.
D. Discussions
1) RQ1 – What are the real trends of local variables interms of their properties? (What are abnormal ones?):
We focused on local variables’ properties: their names,
scopes and types. From the results shown in Tables III and IV,
we can say that variable types have impacts on their naming.
Thus, our classification of variables according to their types
is appropriate for analyzing the features of local variables.
Through the analysis of variables’ names and scopes, we
obtained the following tendencies:
1) For primitive type variables, programmers tend to givenon-compound short names comprised of a few or lesscharacters. It is not uncommon to see one or two-characternames in primitive type variables. Major names are single
English words, their abbreviated forms or their initialletters. It seems to dovetail with the fact that the normal
length of English words is about 3 – 13 characters [10].
The normal length of scope is about 20 or less lines.
2) For reference type variables and arrays of primitive orreference type, programmers often give non-compoundshort names whose lengths are around a few characters

but longer than the ones of primitive types. Their scopes
are at the same level as the primitive type variables.
3) The length of a local variable’s name has no correlation
with its scope length.
Therefore, the majority of local variables in the real Java
programming world seem to conform to the common coding
conventions in terms of the length of names. However, scopes
might be considered less important by many programmers.
From the above results, variables with longer or compound
names or ones with wider scopes seem to be abnormal. Theirabnormal levels are expressed by their Mahalanobis distancefrom the mean vector of features.
2) RQ2 – Is the presence of an abnormal local variable ina Java method related to the method’s change-proneness?:
The abnormality analysis of local variables is worthwhile
if we prove that an abnormal local variable is related to apoor quality of code. We analyzed one of measurable quality
characteristics of Java methods—the change-proneness. As aresult, a method having an abnormal local variable is 1.2 – 2.5
times more likely to be change-prone than the others, where
the differences are statistically significant.
Although the maximum abnormality of local variables ina method seems to be related to change-proneness of themethod, we have just reported the trend that change-prone
methods are likely to have abnormal local variables. Toward
a useful prediction of change-prone methods, we have toperform further analyses of local variables’ abnormalities.
Moreover, we need to clarify the reason why abnormal local
variables are related to change-prone methods. Although there
are concerns about abnormal local variables, e.g., a longname may cause a lack of readability [5], we have not yet
proven whether an abnormal variable caused frequent codechanges or not in the real. In order to see real effects ofabnormal variables, we have to analyze code changes in more
depth. Furthermore, authors of abnormal local variables—who
introduced those variables—would also play an significant rolein understanding the above tendency. These further analyses
are our big challenges in the future.
E. Threats to Validity
We have analyzed large-scale Java OSS products. Since thenotion of local variables is common to many modern programming languages, the difference in the language would not be aserious threat. However, in cases of small-scale OSS products
or commercial ones, a few developers or organization-specificrules may have large impacts on properties of local variables.
In order to enhance the generality of our results, we have toanalyze the author and organization information as well.
Since we collected code changes in methods based on theidentification of methods’ signatures, we might miss some datawhen they were renamed or their arguments were changed. We
must leverage more sophisticated technologies (e.g., Historage[11]) to reduce such a risk. Moreover, we did not see thedetails of code changes, so there might be changes which are
independent of abnormal local variables, or local variables’

names and types might also be changed through the upgrades.
We would tackle those problems as our important future work.
While the Mahalanobis distance is a useful measure todetect abnormal data, the decision of threshold value can bea threat to validity. We need to perform a further analysis toautomatically decide an appropriate threshold in the future, for
producing a better guideline of naming local variables.
V. R ELATED W ORK
Binkley et al. [5] studied a relationship between the humanshort-term memory and the length of identifier through an empirical study with 158 programmers, and reported that a longer
identifier tends to require a longer time to be understood. Thus,
too long of a name seems to be related to a difficulty in code
comprehension. Kawamoto et al. [12] analyzed identifiers usedin Eclipse and NetBeans, and reported that a class having alonger identifier is more fault-prone. Their conclusions statingthat a long name is related to poor quality are common to our
results. However, identifiers in their studies include not only
local variables but also classes and methods. Since names ofclasses or methods may be specified by the design documents,
they would not be at the programmers’ discretions.
Lawrie et al. [4] conducted an empirical study with 128
programmers to compare the understandability of a variable’s
name among three types: (a)fully-spelled word, (b) abbreviatedone and (c)single character. They reported that the understandability showed (a)>(b)>(c), but the difference between(a) and (b) was not statistically significant. Liblit et al. [13]also conducted an empirical study with undergraduates, andreported similar trends with Lawrie et al. work [4]. That is
to say, their studies proved that it is not necessary to givea long name to a variable. We examined such a trend whileconsidering a variable’s type and scope as well.
Aman et al. [14], [15] focused on local variables which havethe maximum scopes in methods, and reported tendencies that
longer names or compound names often appear in changeprone methods. While their work are our important previous
work, they missed the consideration of variables’ types. As wehave seen, the type of variable often impacts on the naming.
We introduced the notion of abnormality while considering thename, the scope and the type of variable in this paper.
VI. C ONCLUSION AND F UTURE W ORK
We focused on local variables in Java methods. Since
the naming of local variables is usually at programmer’s
discretion, we considered it may be a noteworthy point causing
dispersion of code quality. We collected data on local variablesfrom six popular large-scale OSS products, and evaluated theirabnormalities in terms of their names, scopes and types byusing the notion of the Mahalanobis distance. From the results,
we obtained the following findings:
1) The trend of naming local variable differs according to thevariable type: it is worthwhile to classify local variables
in accordance with their types for accurate discussions on
ways of naming local variables.

2) The majority of local variables have short names andnarrow scopes; a name is often a word or its abbreviation.
3) Methods having abnormal local variables are about 1.2 –2.5 times more likely to be change-prone than the others.
Java methods having deviant local variables do not tend tosurvive unscathed after their releases.
However, we have just reported the above trends in thispaper, and we need further analyses of the impacts of abnormal
local variables on the code quality in the future. We planto perform various further analyses focusing on details ofcode changes, changes of abnormalities through upgrades, themeaning of words in variables’ names, the author information and the conventions adopted by the development team.
Moreover, we would like to produce an empirical-data-based
guideline for the naming of local variables as well.
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #16K00099.
The authors would like to thank the anonymous reviewers fortheir helpful comments on an earlier version of this paper.
R EFERENCES[1] B. W. Kernighan and R. Pike, The practice of programming. Boston,
MA: Addison-Wesley Longman, 1999.
[2] Sun Microsystems, “Code conventions for the java programming language,” http://www.oracle.com/technetwork/java/javase/documentation/
codeconvtoc-136057.html, 1999.
[3] Free Software Foundation, “Gnu coding standards,” http://www.gnu.org/
prep/standards/, 2016.
[4] 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.
[5] D. Binkley, D. Lawrie, S. Maex, and C. Morrell, “Identifier lengthand limited programmer memory,” Science of Computer Programming,
vol. 74, no. 7, pp. 430 – 445, May 2009.
[6] J. Gosling, B. Joy, G. Steele, and G. Bracha, The Java Language
Specification, 3rd ed. Boston, MA: Addison-Wesley, 2005.
[7] Google, “Google java style guide,” https://google.github.io/styleguide/javaguide.html, 2017.
[8] D. Boswell and T. Foucher, The Art of Readable Code. Sebastopol,
California: O’Reilly Media, 2011.
[9] G. Taguchi, S. Chowdhury, and Y. Wu, The Mahalanobis-Taguchi
System. NY: McGraw-Hill, 2001.
[10] B. New, L. Ferrand, C. Pallier, and M. Brysbaert, “Reexaming the word
length effect in visual word recognition: New evidence from the english
lexicon project,” Psychonomic Bulletin & Review, vol. 13, no. 1, pp.
45–52, Feb. 2006.
[11] H. Hata, O. Mizuno, and T. Kikuno, “Historage: fine-grained version
control system for java,” in Proc. 12th Int’l Workshop on Principles ofSoftw. Evolution and 7th Annual ERCIM Workshop on Softw. Evolution,
Sept. 2011, pp. 96–100.
[12] K. Kawamoto and O. Mizuno, “Predicting fault-prone modules using thelength of identifiers,” in Proc. 4th Int’l Workshop on Empirical Softw.
Eng. in Practice, Oct. 2012, pp. 30–34.
[13] B. Liblit, A. Begel, and E. Sweetser, “Cognitive perspectives on the roleof naming in computer programs,” in Proc. 18th Annual Psychology ofProgramming Workshop, Sept. 2006.
[14] H. Aman, S. Amasaki, T. Sasaki, and M. Kawahara, “Empirical analysisof change-proneness in methods having local variables with long names
and comments,” in Proc. 9th ACM/IEEE Int’l Symp. Empirical Softw.
Eng. and Measurement, Oct. 2015, pp. 50–53.
[15] H. Aman, S. Amasaki, T. Yokogawa, and M. Kawahara, “Local variables
with compound names and comments as signs of fault-prone java
methods,” in Joint Proc. 4th Int’l Workshop on Quantitative Approaches
to Softw. Quality and 1st Int’l Workshop on Technical Debt Analytics,
Dec. 2016, pp. 4–11.