Empirical Study of Fault-Prone Method’sName and Implementation:
Analysis on Three Prefixes—Get, Set and Be
Sho Suzuki

Hirohisa Aman

Minoru Kawahara

Graduate School of
Science and Engineering,
Ehime University
Matsuyama, Japan 790-8577
Email: s suzuki@se.cite.ehime-u.ac.jp

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

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

Abstract—This paper focuses on the relationship between
Java method’s first word (prefix) and its implementation, forpredicting fault-prone method. As a pilot study of the focused
way of analysis, this paper analyzes three major prefixes ofmethods’ names: “get”, “set” and “be.” The empirical study inthis paper collects many data of methods’ names and implementation features and analyzes abnormality of relationship between
methods’ names and their implementation features. Then, thestudy examines the relationship between a method’s abnormality
and its fault-proneness in eight open source software products.
The empirical results prove the usefulness of focusing on the gap
between methods’ names and their implementation features in
predicting fault-prone methods.

I. I NTRODUCTION
Effective and efficient quality management is essential
to successful software development and maintenance. Many
methods and tools for supporting quality managements havebeen studied and developed in the past. Especially, the faultprone module prediction is one of the most useful topics.
By evaluating fault-proneness of modules before reviewing
and testing them, we can preferentially allocate our humanresources (efforts) to suspicious modules which may havelatent faults [1].
Most previous studies for predicting fault-prone modules
are based on code metrics or process metrics (e.g., [2], [3],[4], [5], [6]). While those studies have been making remarkable contributions to the software engineering community,
there have been a few studies focusing a semantic aspect ofcode—“name” of identifier: Lawrie et al. [7] presented anempirical report showing an impact of the way of naming
identifiers on the source code understandability; Arnaoudova
et al. [8] introduced linguistic anti-patterns of misleading pairsof method’s (field’s) name and implementation. However, there
has not been a study on the relationship between such asemantic aspect and fault-proneness of module to the best of
our knowledge. Thus, toward a more sophisticated fault-prone
module prediction, we perform a fundamental investigation on
relationships of Java methods’ names to their implementationsin this paper.

The remainder of this paper is organized as follows: Section
II describes the way of naming methods in Java and therelationship between a method’s name and its implementation,
along with our related work. Section III reports our preliminary
analysis. Section IV explains our empirical study, and presents
the results and our discussions. Finally, Section V gives ourconclusion and future work.
II. M ETHOD ’ S NAME AND I MPLEMENTATION IN JAVA
A. Method’s name
When a method is developed, the developer has to give ita name which expresses its behavior. Under the limitation of
language specification, developers can give any names to their
methods. In the case of Java, the following conditions mustbe satisfied: a name is not a keyword, a boolean literal or an
empty literal; not a symbol1 ; not started with a number.
Although any names satisfying the above three conditions
are allowed to use, there are recommendations and conventions
for naming methods (e.g., [9], [10]). For instance, the lower
camel case is recommended for the name notation. In thisnotation, all words except for the first one have to start witha uppercase letter (e.g., isJavaIdentifierPart).
Moreover, there are also the following recommendations
in regard to the words to be used: all words used in amethod’s name should be English words or their abbreviations;a method’s name should be a verb or verb phrase; a method’sname should be associated with the method’s behavior; a pairof opposite words should be used for naming a pair of methods
having opposite behaviors each other. For example, a name ofa method which returns a value should start with “get” like
getBytes, and a name of a method which sets a value toan object instance should start with “set” like setSeed. Inorder to give symmetric names to a pair of methods having
opposite tasks, pairs (get, set), (add, remove) and (open,
close) are often used in their naming.
1 But an underscore “ ” and dollar sign “$” are exceptionally available.

B. Relationship between Method’s name and implementation:
Related Work

In order to evaluate a distortion of method’s name, we
require baselines in regard to “normal” relationships between
methods’ names and implementation. Thus, we conducted apreliminary analysis of data to understand the real trends ofmethods in terms of their names and implementation features.
To ensure a generality of our empirical results, we used
Qualitas Corpus created and published by Ewan et al. [14].
This corpus consists of 112 open source software data including their source files, binary files and so on. In this study,
we developed a data collection tool based on JDT [15], andcollected 18 boolean features shown in Table I from eachmethod included in the latest version of source files in the
corpus. Then, we categorized the results in accordance withthe first words of their methods’ names.
Figure 1 shows a part of the results corresponding the top
3 words of names—get, set and be2 : for each word, eachbar chart presents the rate of methods which are “true” at thecorresponding feature.
From Fig. 1, we found the following features are common
to three major named methods: they tend1) to be public method,2) to have neither branch or loop structures,
3) not to create new object instance, and
4) not to throw an exception.
On the other hand, their features in regard to their return
types and parameters showed difference according to the firstwords of their names:
2 Word be corresponds to a be verb such as is, are, etc.

description (each value is either true or false)is the return type voidis the return type boolean
is the return type a primitiveis the return type a reference
has no parameters
has public access modifier
has private access modifier
has protected access modifier
has no access modifier (i.e. package private)
has static modifier
has thrown exceptions in throws
has branch structure (e.g. if statement)
has loop structure (e.g. for statement)does create new object instancehas cast or instanceOf expression
has some return statements
dose throw an exception by itself
has try statement

implemented
NOT implemented

void
bool
prim
ref
noParampublicprivateprotected
none
staticthrowsbranchloop
newtypeCheckreturns
throw
try

0.005
0.017
0.172
0.806
0.714
0.820
0.079
0.061
0.040
0.093
0.077
0.262
0.078
0.179
0.134
0.155
0.048
0.048

0.0

0.2

0.4

0.6

0.8

1.0

Method Implementation Features

implemented
NOT implemented

Method Implementation Features

III. P RELIMINARY A NALYSIS F OCUSING ON F IRST W ORD
OF M ETHOD ’ S NAME

feature
void
bool
prim
ref
noParampublicprivateprotected
none
staticthrowsbranchloop
newtypeCheckreturns
throw
try

void
bool
prim
ref
noParampublicprivateprotected
none
staticthrowsbranchloop
newtypeCheckreturns
throw
try

0.960
0.008
0.004
0.027
0.029
0.878
0.042
0.040
0.041
0.026
0.077
0.260
0.039
0.168
0.069
0.015
0.104
0.030

0.0

0.2

0.4

0.6

0.8

1.0

Rate

Rate

(a) get method(b) set method

implemented
NOT implemented

Method Implementation Features

There have been studies focusing on a relationship between
a method’s name and its implementation. Høst et al. [11]introduced the notion of regularity between a method’s nameand its implementation, and they summarized representative
regularities as a phrase book [12]. Their phrase book presents
the trends of methods in terms of their names and implementation features, which is a concrete collection of methods rather than lists of generalized naming recommendations
given in coding conventions. Moreover, Høst et al. defined a
distortion of method’s name—a mismatch between the nameand the implementation—as “naming bug,” and recommended
to rename the method or to change the implementation.
Arnaoudova et al. [8] also concerned poor quality caused by
an improper combination of names and implementations inmethods. Kashiwabara et al. [13] created association rules inregard to pairs of methods’ names and implementations, andproposed an automated system for suggesting a suitable firstword of name for a method. While all of the above work
are useful for evaluating or improving the quality of code, theimpact of the gap between method’s name and implementationon the fault-proneness has not been examined in the past—thisis our research motivation.

TABLE IC OLLECTED FEATURES FROM EACH JAVA METHOD .

void
bool
prim
ref
noParampublicprivateprotected
none
staticthrowsbranchloop
newtypeCheckreturns
throw
try

0.003
0.984
0.002
0.011
0.611
0.767
0.123
0.062
0.048
0.148
0.040
0.235
0.070
0.042
0.092
0.211
0.022
0.032

0.0

0.2

0.4

0.6

0.8

1.0

Rate

(c) be method
Fig. 1. Implementation features of methods whose names start with get,set or be.

1) get methods tend to have no parameter and return avalue of reference type;2) set methods tend to have one or more parameters andreturn nothing (void);3) be methods tend to have not parameter and return aboolean value.
Based on the above results, we conduct our empirical study
on the distortion of methods’ names in the following section.
IV. E MPIRICAL S TUDY
In this study, we evaluate a distortion of method’s name(naming bug) and examine its impact on fault-proneness ofthe method: we tackle the following research questions (RQs).
RQ1: Is the naming bug noteworthy in predicting faultprone Java methods?
RQ2: Which implementation features are useful in discriminating faulty methods from non-faulty ones?
□
Notice that such a distortion does not always mean a wrong
name because it might be caused by improper implementation
features. In more precise words, a distortion signifies a gap
between the name and the set of implementation features.
A. Data Collection
In this study, we collect data from eight open source
software (OSS) products shown in Table II. We selected themsince their source programs are written in Java and have been
managed with Git. The former reason is from the limitationof the data collection tool we developed, and the latter reason
is to use the Historage [16] for our fine-grained analysis ofcode changes.
To discuss source code quality at the method level, we haveto track method’s changes in their version control repository.
For this reason, we decided to use Historage which is a finegrained version control system developed by Hata et al. A
Historage repository allows us to track changes with respect
to class, method or field. A Git repository can be converted
to Historage one through the Historage-related tool, Kenja3 .
Our data collection is performed in the following procedure.
1) Get clones of repositories:
Make copies of Git repositories on our local disk.
2) Convert Git repositories to Historage ones:
Convert Git repositories gotten in step 1 to Historage
repositories by Kenja
3) Extract histories of each method’s changes from Historage repository:
Extract method-change histories from corresponding
Historage repositories
4) Extract the first word of each method’s name and get its
base form:
Extract the first word of each method’s name by splitting
the name into words with the following regular expressions:∙ _(underscore)
3 https://github.com/niyaton/kenja

TABLE IIS URVEYED OSS PRODUCTS .
product
Eclipse Checkstyle Plug-in
FreeMind
Dr JavaPMD
react-native
retrofit
Universal Image Loader
RxJava# of commits
993
1, 0623, 4669, 0796, 0771, 313
1, 0254, 885

investigation period
2003-05 ∼ 2016-11
2011-02 ∼ 2016-08
2001-06 ∼ 2014-10
2002-06 ∼ 2016-12
2015-01 ∼ 2016-04
2010-09 ∼ 2016-04
2011-11 ∼ 2016-01
2012-03 ∼ 2016-12∙(?<=[a-z])(?=[A-Z])(?<=[A-Z])(?=[A-Z][a-z])∙ (?<=\D)(?=\d)|(?<=\d)(?=\D)
Then, convert the word to its base form by using the
GENIA tagger4
5) Extract each method’s implementation features:
Extract each method’s implementation features as mentioned in Sect. III.
□In our data collection, we excluded (1) constructors, (2)methods in an anonymous class, and (3) methods deployed ina test case directory. The reasons are: (1) names of constructors totally depend on their class names; (2) methods in ananonymous class often have no names; (3) methods deployed
in a test case directory are developed for testing, so an analysisof their fault-proneness seems to be out of our scope in thispaper.
∙

B. Data Analysis
1) Method Classification and Comparison of Fault Rates:
For RQ1, we perform our analysis in the following steps.
1) Extract methods whose names start with get, set orbe; create three sets of methods corresponding to theirfirst words.
2) Divide each set of methods into two subsets: the set of
normal methods vs. the set of abnormal methods.
Take an example of the feature “void” of get methods.
From the results of preliminary analysis shown in Fig.
1(a), we can see that the rate of get methods having
no return value (void) is 0.005. Therefore, if a getmethod has a return value, it is normal; otherwise
it is abnormal. We will judge their abnormality withthreshold 0.05: if a feature’s true rate is less than 0.05,
we consider the feature of a normal method should be
false; if a feature’s true rate is greater than 0.95, we
regard the feature of a normal method should be true. In
this paper, we call such an abnormal case “fatal namingbug,” and consider a method to be abnormal if it has afatal naming bug.
3) Compare the rates of faulty methods (fault rates).
Compare the fault rates between the set of normal methods and that of abnormal methods; we decide whether amethod is faulty or not by checking their commit logs.
2) Which implementation features are useful in discriminating faulty methods from non-faulty ones?:
For RQ 2, we examine the implementation features in thefollowing procedure for each set of get methods, set ones
and be ones:
1) Divide the set of methods into two subsets: the subset
of non-faulty methods and the subset of faulty ones.
2) For each subset, compute the true rates of implementation features.
4 http://www.nactem.ac.uk/GENIA/tagger/0.30

Normal methods
Abnormal methods

TABLE IIIT RUE RATES OF FEATURES AND RESULTS OF STATISTICAL TESTS ( G E T
METHOD ).

0.269

0.20
0.092

0.078

0.074

set methods

be methods

featureprim
refnoParampublicprivateprotected
staticthrowsbranchloop
newtypeCheckreturns

get methods

Fig. 2. Comparison of fault rates.

implemented
NOT implemented

0.154
0.846
0.746
0.854
0.088
0.058
0.073
0.031
0.177
0.057
0.123
0.105
0.103

0.0

0.2

0.4

0.6

0.8

1.0

prim
ref
noParampublicprivateprotected
staticthrowsbranchloop
newtypeCheckreturns

0.093
0.907
0.657

𝑝 value
0.002
0.002< 0.001
0.050< 0.001
0.187
0.026
0.001
< 0.001< 0.001< 0.001< 0.001< 0.001

0.144
0.040
0.106
0.063
0.458

implemented
NOT implemented

0.196
0.280

implemented
NOT implemented

0.343
0.257

0.0

0.2

0.4

0.6

0.8

1.0

Rate

Rate

(a) non-faulty methods(b) − (a)−0.061
0.061−0.089−0.0380.056−0.018
0.033
0.032
0.281
0.139
0.157
0.238
0.154

(b)faulty
0.093
0.907
0.657
0.816
0.144
0.040
0.106
0.063
0.458
0.196
0.280
0.343
0.257

0.816

(b) faulty methods

Fig. 3. True rates of features in get methods.

3) Compare the true rates of implementation features between the set of non-faulty methods and that of faulty
ones, in a statistical way.

Method Implementation Features

prim
ref
noParampublicprivateprotected
staticthrowsbranchloop
newtypeCheckreturns

Method Implementation Features

Method Implementation Features

implemented
NOT implemented(a)non-faulty
0.154
0.846
0.746
0.854
0.088
0.058
0.073
0.031
0.177
0.057
0.123
0.105
0.103

public1.000

throws0.003

branch

0.213

new

0.154

typeCheck

0.025

throw

0.105

0.0

0.2

0.4

0.6

0.8

Method Implementation Features

0.10

0.186

0.00

Fault Rate

0.240

1.0

public1.000

throws0.009

branch

0.350

new

0.205

typeCheck

0.051

throw

0.085

0.0

0.2

Rate

0.4

0.6

0.8

1.0

Rate

(a) non-faulty methods(b) faulty methods

Fig. 4. True rates of features in set methods.

C. Results
1) Is the naming bug noteworthy in predicting fault-prone
Java methods?:
Figure 2 shows the fault rates in the set of normal methods
and that of abnormal methods having a fatal naming bug,for each of get methods, set ones and be ones. From
this figure, we can say that an abnormal method having afatal naming bug is more likely to be faulty than a normal
method: the risks of being faulty are about 2 times, 3 times
and 3.6 times higher in get methods, set methods and bemethods, respectively. Therefore, fatal naming bugs would be
noteworthy in predicting fault-prone Java methods.
2) Which implementation features are useful in discriminating faulty methods from non-faulty ones?:
Figure 3 presents the true rates of implementation features in(a) non-faulty get methods and (b) faulty ones, respectively.
Similarly, Figs. 4 and 5 presents those bar charts for set
methods and be methods, respectively. Tables III, IV and V
compare the true rates of each feature in non-faulty methods
and in faulty ones, and the results of statistical tests (𝑝 values)
examining the differences between their true rates, for get
methods, set ones and be ones, respectively.
For get methods, faulty methods are more likely to havethe following eight features: 1) having a branch structure (e.g.,
if statement), 2) having a cast expression or instanceOf
operator, 3) having multiple return statements, 4) having aloop structure (e.g., for statement), 5) having no parameter,6) being private method, 7) being static method, and 8) having
throws statement.
For set methods, the presence of a branch structure is
only the feature which is more frequently observed in faulty
methods than non-faulty ones.
For be methods, faulty methods tend to have the following
five features: 1) having a branch structure, 2) having a cast
expression or instanceOf operator, 3) having multiple
return statements, 4) being a private method, and 5) having
a parameter. From the above trends, we can say that normal
be methods are usually public, instance methods which haveno parameter and no branch structure, do not special dataprocessing, and do not have multiple return statements.
Moreover, as shown in Fig. 2, the difference of fault rates
between the set of non-faulty be methods and that of faulty

TABLE IV
T RUE RATES OF FEATURES AND RESULTS OF STATISTICAL TESTS ( S E T
METHOD ).
featurepublicthrowsbranchnew
typeCheckthrow(a)non-faulty
1.000
0.003
0.213
0.154
0.025
0.105

(b)faulty
1.000
0.009
0.350
0.205
0.051
0.085

(b) − (a)
0.000
0.006
0.137
0.051
0.026
−0.020𝑝 valueNA
0.903< 0.001
0.184
0.179
0.625

noParam

0.711

public0.865

private

0.111

protected

0.023

static0.080

branch

0.143

loop

0.059

typeCheck

0.074

returns
0.2

0.4

0.6

0.8

noParam

0.485

public0.711

private

0.289

protected

0.000

static0.155

branch

0.412

loop

0.124

typeCheck

0.278

returns

0.122

0.0

public int getWidth() {return width;}

implemented
NOT implemented

Method Implementation Features

Method Implementation Features

implemented
NOT implemented

1.0

0.392

0.0

0.2

Rate

0.4

0.6

0.8

1.0

Rate

(a) non-faulty methods(b) faulty methods

Fig. 5. True rates of features in be methods.
TABLE VT RUE RATES OF FEATURES AND RESULTS OF STATISTICAL TESTS ( B E
METHOD ).
featurenoParampublicprivateprotected
staticbranchloop
typeCheckreturns(a)non-faulty
0.711
0.865
0.111
0.023
0.080
0.143
0.059
0.074
0.122

(b)faulty
0.485
0.711
0.289
0.000
0.155
0.412
0.124
0.278
0.392

(b) − (a)−0.226−0.1540.178−0.023
0.075
0.269
0.065
0.204
0.270

𝑝 value< 0.001< 0.001< 0.0010.250
0.019< 0.001
0.021< 0.001< 0.001

be methods is larger than the cases of get methods andset ones. Thus, be methods are possibly easier to be more
complicated. While get methods and set ones usually play
the roles of accessors to values, be methods may be required
more complex processes in regard to judgments involved inmany other data or status of objects.
D. Discussions
1) get method:
Figure 6(a) shows an example of method which has nofatal naming bug. This method is included in ImageSize.javaof Universal Image Lorder; the class of this method has two
fields height and width. This method returns the value ofwidth, which looks a normal get method.
On the other hand, Fig. 6(b) shows an method having afatal naming bug on the return type, which is included in
MindMapMapModel.java of FreeMind. This method does not
return anything, but writes strings via Writer object. Fromname getXml, many programmers may assume that it returns
a data of XML format. That is to say, this implementation is
confusable and may cause unexpected faults.
2) set method:
Figure 7(a) shows an example of a normal method which
has no fatal naming bug. This method appears in ImportDeclaration.java of DrJava; the class has a string field name. Then,
this method sets a value to the field unless a parameter value
is null, which seems to be one of general set methods.
On the other hand, the method shown in Fig. 7(b) is abnormal, which is included in LanguageVersionDiscoverer.java of
PMD. The strangest point is at its return type (reference type).

(a) A normal get method (ImageSize.java of Universal Image Lorder).
/*** writes the content of the map to a writer.
** @throws IOException*/
public void getXml(Writer fileout, boolean saveInvisible,
MindMapNode pRootNode) throws IOException {fileout.write("<map ");fileout.write("version=\"" + FreeMind.XML_VERSION + "\"");
fileout.write(">\n");fileout.write("<!-- To view this file, download free mind mapping software
FreeMind from http://freemind.sourceforge.net -->\n");pRootNode.save(fileout, this.getLinkRegistry(), saveInvisible, true);
fileout.write("</map>\n");fileout.close();}(b) An abnormal get method (MindMapMapModel.java of FreeMind).
Fig. 6. Examples of get methods.

As shown in Fig. 1(b), it is really rare that a set method
has such a return value. As described in its Javadoc (see Fig.
7(b)), this method sets a given value as the current language
information and returns previous language information. However, in this case, these behaviors can be divided into two sub
methods, i.e., this method should be refactored. In the future,
we would like to automatically recommend a code refactoring
to such a method, based on our research results.
3) be method:
Figure 8(a) shows an example of normal method included in
NodeAdapter.java of FreeMind. This method judges whether
the state of Filter instance is visible or not. In the concrete,
this method first gets Filter instance by method invocations,then performs the logical operation using the result. As shownin Fig. 8(a), it returns a boolean value, does not have any/*** Sets the package name* @exception IllegalArgumentException if s is null*/public void setName(String s) {if (s == null) throw new IllegalArgumentException("s == null");name = s;}(a) A normal set method (ImportDeclaration.java of DrJava).
/*** Set the given LanguageVersion as the current default for it’s Language.
** @param languageVersion
The new default for the Language.
** @return The previous default version for the language.
*/
public LanguageVersion setDefaultLanguageVersion(LanguageVersion
languageVersion) {LanguageVersion currentLanguageVersion = languageToLanguageVersion.put(
languageVersion.getLanguage(),languageVersion);
if (currentLanguageVersion == null) {currentLanguageVersion = languageVersion.getLanguage().getDefaultVersion();}
return currentLanguageVersion;}(b) An abnormal set method (LanguageVersionDiscoverer.java of
PMD).
Fig. 7. Examples of set methods.

public boolean isVisible() {Filter filter = getMap().getFilter();
return filter == null || filter.isVisible(this);}(a) A normal be method (NodeAdapter.java of FreeMind).
/*** True if there is a shared map at present, false otherwise. If this value* is false, the sender will ignore requests to send Freemind commands.
** @param shared*/public void isMapShared(boolean shared) {mapShared = shared;}(b) An abnormal be method (JabberSender.java of FreeMind).
Fig. 8. Examples of be methods.

parameter and complex implementations. This method would
be one of representative be methods.
On the other hand, the method shown in Fig. 8(b) has afatal naming bug on its return type. This method appears in
JabberSender.java of FreeMind. According to its return type
and Javadoc description, this method does not judge anything.
Moreover, it sets a parameter value to field mapShared. In
this case, we consider that the method should be set one;this method’s name is confusable and may be troublesome.
E. Threat to Validity
There are concerns in regard to our data collection.
Since we used the Qualitas Corpus in our preliminary
analysis to understand the real trends of methods in terms of
their names and implementation features in Sect. III, there may
be a kind of data bias. Moreover, we did not considered thesize of data—the number of methods in each product. Thus,
the preliminary results are possibly affected by a few largescale software products. There is a similar threat to validity
for the empirical results in Sect. IV. While we mitigatedsuch threats by using a lot of methods from many productsof various domains, replication studies would be required toprove the generality of our results.
While we excluded test programs, there might be missfiltered cases because we carried out the exclusion by using asimple pattern matching to their source path name. However,test programs are not usually mixed into the same directories
as application programs, so the way of excluding testing code
would not be serious threat to validity in our study.
We used Historage repositories to track method change
histories, thus the reliability of code change data depends
on the Historage technology. Since the Historage technology
has been actively leveraged in the mining software repositorycommunity, we believe that it is not our threat to validity.
V. C ONCLUSION
Toward yet another way of predicting faulty methods, wehave focused on the gap between method’s name and its
implementation—a naming bug. As a pilot study, we analyzed
major methods whose prefixes of names are “get,” “set” and“be” in this paper.

In our empirical study with open source products, weclassified the set of methods into the set of normal methods
and that of abnormal methods in terms of fatal naming bug,and compared their fault rates. The results showed that thefault rates of abnormal methods are 2 – 3.6 times larger thannormal ones. Therefore, we can say that fatal naming bugs arenoteworthy for fault-prone method prediction.
Moreover, we conducted a further analysis on which implementation features are useful in predicting faulty methods,
and found remarkable points to be checked for each of getmethod, set method and be method, respectively. Thosecheck points would be useful clues during their code reviews.
In the future, we plan to perform a further analysis on
methods whose prefixes of names are not only “get,” “set” and“be’ but also other verbs in order to enhance the generality of
our results and the accuracy of prediction.
R EFERENCES[1] P. L. Li, J. Herbsleb, M. Shaw, and B. Robinson, “Experiences and results from initiating field defect prediction and product test prioritization
efforts at ABB Inc.” in Proc. 28th Int’l Conf. Softw. Eng., May 2006,
pp. 413–422.
[2] T. M. Khoshgoftaar and N. Seliya, “Comparative assessment of software
quality classification techniques: An empirical case study,” Empirical
Softw. Eng., vol. 9, no. 3, pp. 229–257, Sept. 2004.
[3] S. Lessmann, B. Baesens, C. Mues, and S. Pietsch, “Benchmarking classification models for software defect prediction: A proposed frameworkand novel findings,” IEEE Trans. Softw. Eng., vol. 34, no. 4, pp. 485–
496, July 2008.
[4] Y. Liu, T. Khoshgoftaar, and N. Seliya, “Evolutionary optimizationof software quality modeling with multiple repositories,” IEEE Trans.
Softw. Eng., vol. 36, no. 6, pp. 852–864, Nov. 2010.
[5] R. Moser, W. Pedrycz, and G. Succi, “A comparative analysis of
the efficiency of change metrics and static code attributes for defectprediction,” in Proc. ACM/IEEE 30th Int’l Conf. Softw. Eng., May 2008,
pp. 181–190.
[6] F. Rahman and P. Devanbu, “How, and why, process metrics are better,”in Proc. 2013 Int’l Conf. on Softw. Eng., May 2013, pp. 432–441.
[7] 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.
[8] V. Arnaoudova, M. D. Penta, G. Antoniol, and Y. G. Guhneuc, “A new
family of software anti-patterns: Linguistic anti-patterns,” in Proc. 17th
European Conf. Softw. Maintenance and Reengineering, March 2013,
pp. 187–196.
[9] Oracle, “The java language specification, java se 8 edition,”
http://docs.oracle.com/javase/specs/jls/se8/html/index.html, Feb. 2015.
[10] Google, “Google java style,”
https://google.github.io/styleguide/javaguide.html, Mar. 2014.
[11] E. W. Høst and B. M. Østvold, “The programmer’s lexicon, volume i:
The verbs,” in Proc. 7th IEEE Int’l Working Conf. Source Code Analysis
and Manipulation, Sept. 2007, pp. 193–202.
[12] ——, “The java programmers phrase book,” in Softw. Language Eng.,
ser. Lecture Notes in Computer Science, D. Gašević, R. Lämmel, andE. V. Wyk, Eds., vol. 5452. Springer Berlin Heidelberg, 2009, pp.
322–341.
[13] Y. Kashiwabara, T. Ishio, H. Hata, and K. Inoue, “Method verb recommendation using association rule mining in a set of existing projects,”
IEICE Trans. Inf. & Syst., vol. E98-D, no. 3, pp. 627–636, Mar. 2015.
[14] E. Tempero, C. Anslow, J. Dietrich, T. Han, J. Li, M. Lumpe, H. Melton,
and J. Noble, “Qualitas corpus: A curated collection of java code for
empirical studies,” in 2010 Asia Pacific Softw. Eng. Conf., Dec. 2010,
pp. 336–345.
[15] The Eclipse Foundation, “Eclipse java development tools (jdt),”
http://www.eclipse.org/jdt/, Jan. 2017.
[16] 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,
2011, pp. 96–100.