An Investigation of Compound Variable Names Toward
Automated Detection of Confusing Variable Pairs
Hirohisa Aman∗ , Sousuke Amasaki† , Tomoyuki Yokogawa† , Minoru Kawahara∗∗ Center for Information Technology, Ehime University, Matsuyama, 790–8577 Japan

Email: {aman, kawahara}@ehime-u.ac.jp† Faculty of Computer Sc. & Systems Eng., Okayama Prefectural University, Soja, 719–1197 Japan

Email: {amasaki, t-yokoga}@cse.oka-pu.ac.jp

Abstract—A successful naming of variables is key to making
the source code readable. Programmers may use a compound
variable name by concatenating two or more words to makeit easier to understand and more informative. While eachcompound variable name itself may be easy-to-understand, acollection of such variables sometimes makes a “confusing”
variable pair if their names are highly similar, e.g., “shippingHeight,” vs. “shippingWeight.” A confusing variable pairwould adversely affect the code readability because it may cause amisreading or a mix-up of variables. Toward automated support
for enhancing the code readability, this paper conducts a largescale investigation of compound variable names in Java programs
to ﬁnd quantitative criteria of the confusing variable pairs.
The investigation collects 31,806,749 pairs of compound-named
variables from 684 open-source Java projects and analyzes themfrom two different perspectives of name similarity: the string
similarity and the semantic similarity.
Index Terms—Confusing variable names, string similarity,
semantic similarity.

I. I NTRODUCTION
Programmers usually declare and use variables in theirprograms. Variables are fundamental components of programs,
and variables’ names have signiﬁcant impacts on code readability [1]–[3]. Well-chosen names would make the codereadable and help developers understanding and reviewing the
program smoothly. On the other hand, poorly-chosen names
degrade the code readability: if we replace the variable nameswith unrelated (meaningless) strings, we can easily obfuscate
our programs [4], [5].
To make a variable name easy to understand, many programmers use English dictionary words or well-known abbreviations for the name [6]. The usefulness of choosing fully
spelled words or abbreviations for variable names has been
empirically proved in the past [7], [8]. When the role of thevariable becomes complex, it is helpful to use a compound
name [9] that is organized by two or more words, like“positionOfPlayer.” Because a compound name corresponds
to a phrase describing the variable, many programmers andcode reviewers can easily understand the variable’s role. The
positive effect provided by a compound name has also been
proved in empirical studies [10].
However, there is also a negative effect of compound names
on code readability. Tashima et al. [11] proposed the notionof confusing variable pairs, where two variables have highly
similar names like “lineIndex” and “lineIndent.” Due to theirhigh similarity, they cause a risk of misreading or mixing up
variables during the programming or code review. Thus, they
may adversely affect the code readability even though eachvariable name is understandable. Aman et al. [12] reported
an empirical study showing that confusing variable pairs
are related to a deterioration of code quality. Hence, it issigniﬁcant to detect confusing variable pairs for successfulcode readability management.
Although the previous studies [11], [12] measured thesimilarity between variable names using the Levenshtein distance [13], they missed the semantic perspective. For example,
we may consider “stackNum” to be similar to “stackCount”
because we can use the word “count” instead of “number”(“num”) in many contexts. It is better to consider boththe string and semantic similarity to examine the confusing
variable pairs. This paper conducts a large-scale investigationof compound variable names to analyze the name similarity
from both the string similarity and the semantic similarity
perspectives as a preliminary work toward an automated detection of confusing variable pairs. The analysis result presents
quantitative criteria to detect confusing variable pairs.
II. C OMPOUND VARIABLE NAME AND NAME S IMILARITY
In this section, we describe the variable name of interest, thecompound name. Then, we introduce the notion of confusing
variable pairs and explain metrics for detecting those pairs.
A. Compound Variable Name
It is desirable that a variable’s name clearly expresses
its role in the program. To this end, programmers would
choose a fully spelled word or its abbreviated form as avariable name. However, there are also cases that it is hard
to express a variable’s name by a single word because its roleis complicated. For such variables, programmers tend to use
compound names that consist of two or more terms (words
or abbreviations). A compound variable name is produced byconcatenating terms. The camelCase and the snake case are
the most popular naming styles [9]. In the camelCase, we
join all terms and capitalize the initial character of the secondor later terms to indicate the separation. In the snake case,
we indicate the separation of terms by the underscore (“ ”).
For example, if we make a name from “data ﬁle name,” thecompound names in the camelCase and the snake case can be“dataFileName” and “data ﬁle name,” respectively.
Some programmers produce a compound variable nameby concatenating two or more terms without any indicationof separation, such as “ﬁlename”(ﬁle + name), because theelement terms are simple and widely used. Although it ischallenging to deﬁne the simple-concatenated compound nameclearly, we regard a name as a compound variable name in thispaper if we can split it into English dictionary words or wellknown abbreviations1 .
B. Confusing Variable Pair
A compound variable name seems to be a phrase describing
the role of the variable. Thus, it is understandable for many
programmers and code reviewers without additional descriptions, such as the comments in the program. However, when
we have two or more well-described compound names in ourcode fragment, they may cause a side effect on the codereadability. If those compound variable names are similar toeach other, they can be confusing variable pairs [11], [12].
Some programmers or code reviewers mix up those variables
during the programming or reviewing activities, even thougheach compound variable name is understandable.
Figure 1 shows an example of the situation where a
programmer encounters confusing variable pairs during theirprogramming on Eclipse, an integrated development environment (IDE). In this example, the programmer is about towrite “shippingWeight,” and the IDE suggests candidates
whose names are highly similar to each other. Because theﬁrst six candidates are the same-typed variables, the IDE
would not warn even if the programmer selected a variable
incorrectly. Moreover, suppose the programmer wrongly chose“shippmingMaxWeight” for it. In that case, the programmer
and the code reviewers may not quickly ﬁnd the mistakebecause “shippingWeight” and “shippmingMaxWeight” arehighly similar to each other in terms of both the string
similarity and the semantic similarity. Although the above caseshown in Fig. 1 is just an example, it illustrates the risk of thevariable mix-up caused by confusing variable pairs.
Here, we formally deﬁne the confusing variable pair below.
Deﬁnition 1 (confusing variable pair): We consider two
variables v1 and v2 in a program P , and their names arename(v1 ) and name(v2 ). Let the line number intervals S(v1 ) =[b1 , e1 ] and S(v2 ) = [b2 , e2 ] be the scopes of v1 and v2 ,respectively; That is, v1 is available between the b1 -th line

Fig. 1. An example of confusing variable names that we may encounter
during our programming activity.
1 We leverage GNU Aspell 0.60.6.1 to check words.

and the e1 -th line in P , and v2 is available between the b2 -thline and the e2 -th line. Let type(v1 ) and type(v2 ) be the datatypes of v1 and v2 , respectively. We deﬁne the pair (v1 , v2 ) tobe confusing variable pairs if it satisﬁes all of the following
conditions: (1) S(v1 ) ∩ S(v2 ) ̸= ∅, (2) type(v1 ) = type(v2 ),and (3) name(v1 ) and name(v2 ) are similar to each other.
Condition (1) focuses on whether both variables are available simultaneously or not. If there is an overlap between
their scopes, they can be candidates of a confusing variable
pair. Condition (2) ﬁlters out different-typed variables because
it is easy to ﬁnd a mix-up case when the variable’s type
differs from the expected one; The IDE or the compiler would
issue a warning. Although there are some combinations ofdifferent data types such that one type can be a substitute foranother type, we adopt the above straightforward deﬁnition inthis paper. Because the type compatibility checking requires
a detailed and rich program analysis, it is costly in our largescale investigation; it is our future work. Condition (3) remains
to be clearly deﬁned. To overcome it, we have to deﬁne
the similarity between variables. There can be two different
perspectives: the string similarity and the semantic similarity.
We describe these similarities in Sections II-C and II-D.
C. String Similarity
When two variable names have a common part (substring),
they might be similar; The larger the common part is,
the more similar they look. For example, a variable name“shippingHeight” looks more similar to “shippingWeight”
than “productHeight.” We can quantify such a string similarity by focusing on how many characters we should edit
to convert one name to another. A character edit is one ofcharacter addition, deletion, and substitution. Then, the least
number of character edits to convert can be an index of string
dissimilarity, referred to as the Levenshtein distance [13].
We can quantitatively compare the difference of the similarity in the above example as follows. For the sakeof convenience, we denote the Levenshtein distance between name 1 and name 2 by dL (name 1 , name 2 ). Then,
we obtain dL (“shippingHeight”, “shippingWeight”) = 1 anddL (“shippingHeight”, “productHeight”) = 8, where, for theﬁrst pair, we can convert name 1 to name 2 by only substituting“H” with “W,” i.e., the least number of required character edits
is one; On the other hand, for the second pair, we need eightcharacter substitutions to convert name 1 to name 2 .
Although dL reasonably measures how two names lookdifferent, the length of the name may also affect the similarity evaluation. For example, while the following two pairs
have the same Levenshtein distance (dL (·, ·) = 1), the similarity level does not look identical: (“ﬁleA”, “ﬁleB”) and(“distanceBetweenAandB”, “distanceBetweenAandC”).
To take account of such a difference as well, we consider thefollowing normalized Levenshtein distance, ndL :ndL (name 1 , name 2 ) =dL (name 1 , name 2 ),max{ λ(name 1 ), λ(name 2 ) }where λ(name k ) is the length of name k (for k = 1, 2). Then,
we can successfully reevaluate the above example pairs: ndLvalues of (“ﬁleA”, “ﬁleB”) and (“distanceBetweenAandB”,“distanceBetweenAandC”) are 0.2 and 0.05, respectively.
Because the distance is an inverse measure of similarity, we
use the following Levenshtein similarity, sim L , in this paper:

names. By computing the similarity between vectors, we canobtain the degree to which two names are semantically similar.
In this study, our metric of similarity between vectors is the
cosine similarity. The range of similarity is [−1, 1]; The higher
value the variable pair has, the more similar they are.

sim L (name 1 , name 2 ) = 1 − ndL (name 1 , name 2 ) .

Through the above steps, for instance, we would be able toautomatically judge that “stackNum” is similar to the following names: “numStack,” “countStack,” and “stackCount.”

The range of sim L value is [0, 1]. The higher value the pairhas, the more similar they are.
D. Semantic Similarity
There have been techniques for quantitatively representing
the semantics of words in natural language processing studies:word embeddings. An embedding is a numerical vector representation of a word. Word2Vec [14] is one of the most popularmodels to produce word embeddings using the neural network.
It learns the associations of words in the training data (texts),
and Word2Vec uses the trained network to produce the corresponding word vectors. Because semantically similar words
are likely to appear in a similar context, the corresponding
vectors can also become close in the resulting vector space.
That is, we can evaluate the semantic similarity between words
using the closeness between the corresponding vectors. To
produce the document (sequence of words) embedding rather
than the word embedding, an extended version of Word2Vec
has been developed: Doc2Vec [15]. We can also evaluate thesemantic similarity between documents using Doc2Vec.
By splitting a compound variable name into its element
words, we can regard the variable name as a document. Hence,
we can also measure the semantic similarity between variablenames using Doc2Vec through such a name splitting. We
explain the steps to produce document vectors for compound
variable names below.
(1) Name Splitting: We split a compound variable name by
the camelCase or the snake case2 . For a simply-concatenatedname like “ﬁlename,” we consider all available patterns ofsplitting into two terms3 and check if both terms are in adictionary or not.
(2) Preprocessing: We decapitalize all words to avoid thedifference in letter case affects the vectorization. After that, we
perform the stemming of the word to uniform the word styles
because a word can appear in different styles like “list,” “lists,”“listed,” and “listing.” Furthermore, we sometimes encountera variable name using a number such as “inputBuffer2.”
Although the number is a part of the name, it would not beessential for considering the meaning of the variable name.
To avoid any impact caused by such a number, we replace
all numbers appearing in a compound variable name with thespecial token “<num>.”(3) Vectorizing: After the above processings of variablenames, we train the Doc2Vec model and vectorize those
2 We used the regular expressions “[a-z][A-Z]” and “_” as our simple
delimiters.
3 We split a name so that both the lengths of split names are longer than
two characters to avoid many wrong extractions of “a” or “an.”III. Q UANTITATIVE I NVESTIGATION
We conducted a large-scale investigation of compound variable names. In this section, we report and discuss the results.
A. AimToward an automated detection of confusing variable pairs,
we need to develop reasonable criteria regarding the variablename similarity. By examining the name similarity trends(distributions) in the actual programming world, we can see
a practical threshold level of similarity to judge whether apair of compound variable names is confusing or not. Ourinvestigation aims to ﬁnd such criteria in terms of string
similarity and semantic similarity.
B. Data Collection
We collected 1000 repositories of open-source Java projects
from GitHub. We selected them by searching projects withthe keyword “Java” in the descending order of the “stars”
score. The number of collected projects (1000) is from thelimitation of GitHub API. We developed a program analysis
tool, JavaVariableScopeExtractor, that analyzes Java source
ﬁles to extract variables with their data type and scope
information. Because our tool supports only Java, we had tolimit our investigation into Java projects.
We performed our data collection in the following procedure; Table I shows our environment.
(1) We obtained project information via GitHub API and madeclones of Git repositories for each project.
(2) We analyzed all Java source ﬁles and extracted all variables
using our tool. Variables include local variables, methods’
formal parameters, and classes’ ﬁelds. In our analysis, we excluded programs for testing, demo, or documentation because
they are not the primary products of the development.
(3) We checked the names of all variables and picked upcompound variable names from them. Then, we built the set ofvariable pairs where two variables are simultaneously available

TABLE IDATA C OLLECTION E NVIRONMENT AND H YPERPARAMETER
Item
CPU
MemoryOS
Pythonstemmer
Doc2Vec

Description
Intel Core i5-4570 3.20GHz
16GB
Linux 3.10.0
Python 3.6.8
PorterStemmer on nltk 3.5
Doc2Vec on gensim 3.8.3 (vector size=300, window=2,
dm=1, min count=1, epochs=100)

within a scope, and their data types are the same.
(4) For each variable pair, we measured the string similarity
and the semantic similarity to examine if it can be a confusing
variable pair or not.
C. Results
As a result of our data collection, we successfully analyzed
60,908 Java source ﬁles from 684 projects4 . The remaining
316 projects corresponded to any of the following ones: (a)they have no Java source ﬁles, (b) all source ﬁles are to be
excluded ones such as test programs, or (c) our analysis tool
failed to parse the source ﬁles because multi-byte characters
appeared in the variable names.
From the above source ﬁles, we collected 1,377,219 variables, and 563,445 out of them (40%) were the variables withcompound names. By checking their types and scopes, wefound 31,806,749 pairs as candidates for confusing variable
pairs in this study.
We measured the string similarity and the semantic similarity for each pair. Figure 2 and Table II show the distributions ofsimilarity scores and the descriptive statistics. Because there
are the variable pairs where two names are the same5 , themaximum string similarity is 1.0; Notice that Doc2Vec’s vector
production has an instability caused by random numbers, so
the maximum semantic similarity is not equal to 1.0 even if
the names are the same.
From the results of similarity measurement, we can seethat most variable pairs have relatively low similarity in termsof both the string similarity and the semantic similarity: themedians of the string similarity and the semantic one are 0.222
and 0.115, respectively. In other words, there are not many
variable pairs such that they look confusing (highly similar)in the actual Java programming world. We believe such a trend
is natural and consistent with our programming practice, i.e.,
we are likely to avoid using the confusing variable pairs in
our programs.

2000000

Number of Variable Pairs

Number of Variable Pairs

3e+06

2e+06

1e+06

1500000

D. Discussion
To detect confusing variable pairs while considering thesimilarity distribution, we use the mean (µ) and the standard
deviation (σ). When a value is greater than µ + 3σ, we canregard it as an extremely high value. In the resulting dataset,µ and σ are µstr = 0.230, σstr = 0.130, µsem = 0.151, andσsem = 0.179, where the subscripts str and sem signify thestring similarity and the semantic one, respectively. Then, we
obtain thresholds of similarity as: µstr + 3σstr = 0.619 andµsem + 3σsem = 0.686 . By using the above thresholds, weconsider criteria of confusing variable pairs. To reasonably
combine two measures, we need to pay attention to theircorrelation. We examined the correlation between the similarity scores using Spearman’s ρ, and we conﬁrmed no strong
correlation between them (ρ = 0.177). Hence, we can integrate
the above criteria in an orthogonal way, i.e., our criteria are:
• Is the string similarity is higher than 0.619?, and• Is the semantic similarity is higher than 0.686?
As a result, 348,909 pairs and 383,593 pairs have the string
similarities and the semantic similarities higher than the above
thresholds, respectively (except for the same name pairs);
161,224 pairs (0.5%) satisﬁed both of two criteria. Table III
shows samples from our data: No.1–4 are the pairs satisfying
both of the above criteria, and No.5–8 are the ones satisfying
only one of them. Pair No.1 looks like a similar pair, but it may
not be hard to distinguish them; We may say its confusing levelis relatively “Low” because both similarity scores are close
to the thresholds. However, pair No.4 must be a confusing
variable pair; We would say its confusing level is “High.”
Pairs No.5–6 are samples of high string similarity, but low
semantic similarity; Pairs No.7–8 are opposite cases, i.e., pairs
with low string similarity but high semantic similarity. The
former samples may look like confusing pairs as the previous
studies [11], [12] because of their high string similarity scores.
Furthermore, our proposal covers the latter samples as well.
Although they may not look like similar names in terms ofstring similarity, there is a risk of mixing those variables whileconsidering the variables’ roles because of their semanticallysimilar names.

1000000

TABLE IIIE XAMPLES OF S TUDIED VARIABLE PAIRS

500000

0e+00

0
0.00

0.25

0.50

0.75

1.00

−0.5

String Similarity

0.0

0.5

1.0

Semantic Similarity(a) string similarity

No. Variable Name Pair(b) semantic similarity

Fig. 2. Histograms of similarity scores.

2
3

TABLE II
D ESCRIPTIVE S TATISTICS OF S IMILARITY S CORESStringSemanticMin
0.000–0.572

25%
0.159
0.034

50%
0.222
0.115

Mean
0.230
0.151

75%
0.281
0.221

4
Max
1.000
0.988

4 Our dataset is available at https://bit.ly/3zH8HEd.
5 For instance, one variable is a class’s ﬁeld, and another is a local variable

in a method.

1

5
6
7
8

Similarity
String Semantic

sentinelConnectionTimeout
sentinelSoTimeout
lookupDeﬁneClassMethod
lookupDeﬁneClass
singleFlatMapObservable
singleFlatMapHideObservable
btGeneric6DofSpringConstraintDataName
btGeneric6DofSpring2ConstraintDataName

0.640

0.758

0.739

0.889

0.852

0.824

0.974

0.903

getAlgorithmConstraints
setAlgorithmConstraints
GradientColor android centerY
GradientColor android endY

0.957

0.131

0.862

0.398

PUBLIC KEY
publicKey
edenUsedsurvivorUsed

0.100

0.921

0.333

0.897

From these results, our approach seems to detect confusing
variable pairs successfully. Because the above thresholds ofsimilarity is an example using the notion of “µ + 3σ,” wecan leave them as user-adjustable parameters when implementing an automated detection tool. To decide more practicalthresholds, we need to analyze the relationship of the above
similarity scores with the manual evaluations. Toward a better
threshold setting, we plan to conduct a questionnaire study
regarding the variable names’ confusing level in the future.
E. Threats to Validity
1) Internal Validity: The way of splitting variable names
can be a threat to internal validity. Although we split compound names using simple regular expressions, they mightcause inappropriately split names in our dataset. A richer
splitting tool6 might be a better choice in our investigation.
We measured the semantic similarity using the Doc2Vec
model. Because its performance depends on the hyperparameters, their setting can be our threat to internal validity. To
mitigate this threat, we preliminary experimented with various combinations of two major hyperparameters, vector sizeand epochs. Because the Doc2Vec model steadily produced
almost the same vectors for the same names when we set
vector size=300 and epochs=100, we used them in ourstudy. However, there might be a better setting, and we might
miss a more proper model for evaluating semantic similarity.
2) Construct Validity: We adopted the Levenshtein similarity as our measure of the string similarity. Moreover, we usedthe cosine similarity between the document vectors obtainedby Doc2Vec, to evaluate the semantic similarity. Althoughthese measures are widely used ones, there might be otherbetter ways of measuring those similarities. To ensure that ourmeasures properly quantify the similarity of interest, we needto prepare a dataset of variable pairs where the similarities areevaluated manually. Because it is costly and not easy work,
we would discuss it continuously as a future issue.
3) External Validity: Although we conducted a large-scale
investigation and analyzed many variable names in various
programs, it is limited to open-source Java projects. Other
projects using other languages or commercial projects maylead to different results. Because there are language-speciﬁcfeatures or practices in naming variables, we plan to perform
other investigations on other language projects in the future.
IV. C ONCLUSION AND F UTURE W ORK
In this paper, we focused on compound variable names
appearing in programs. Although compound names themselves
are easy to understand, there is a risk that they can be
confusing variable pairs when their names are highly similar.
Because the confusing variable pairs may adversely affect thecode readability, it is better to detect such pairs automatically.
Toward the development of an automated detection tool, we
conducted a large-scale investigation of compound names.
In our study, we collected 31,806,749 variable pairs from
684 open-source Java projects. Then, we measured the name
6 e.g., Spiral, https://github.com/casics/spiralsimilarity of them from two different perspectives: the string
similarity and the semantic similarity. We used the Levenshtein
distance and the Doc2Vec as our methods for measuring thosesimilarities. As a result, we found that we may use 0.619 and
0.686 as the thresholds of the string similarity and the semantic
similarity to detect confusing variable pairs, respectively. Note:
Our dataset is available at https://bit.ly/3zH8HEd.
Our future work includes (1) developing an automated detection tool using our ﬁndings, (2) conducting a questionnaire
study on practical thresholds of similarity scores, (3) further
investigations on other software projects using languages otherthan Java, and (4) considering the ambiguity of variable names
from the perspective of linguistic antipatterns [16].
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #20H04184,#21K11831, and #21K11833.
R EFERENCES[1] F. Deissenboeck and M. Pizka, “Concise and consistent naming,” Softw.
Q. J., vol. 14, no. 3, pp. 261–282, Sept. 2006.
[2] D. E. Knuth, Selected Papers on Computer Languages, CSLI Lecture
Notes. Stanford, CA, 2003, no. 139.
[3] T. M. Pigoski, Practical Software Maintenance: Best Practices forManaging Your Software Investment. N.J.: Wiley Publishing, 1996.
[4] M. Ceccato, M. Di Penta, P. Falcarin, F. Ricca, M. Torchiano, andP. Tonella, “A family of experiments to assess the effectiveness andefﬁciency of source code obfuscation techniques,” Empir. Softw. Eng.,
vol. 19, no. 4, pp. 1040–1074, Aug 2014.
[5] D. Low, “Protecting java code via code obfuscation,” Crossroads,
vol. 4, no. 3, pp. 21–23, Apr. 1998.
[6] 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, pp. 53–67.
[7] D. Lawrie, C. Morrell, H. Feild, and D. Binkley, “Effective identiﬁer
names for comprehension and memory,” Innovations in Systems &Softw. Eng., vol. 3, no. 4, pp. 303–318, Dec. 2007.
[8] G. Scanniello, M. Risi, P. Tramontana, and S. Romano, “Fixing faults
in c and java source code: Abbreviated vs. full-word identiﬁer names,”
ACM Trans. Softw. Eng. Methodol., vol. 26, no. 2, pp. 6:1–6:43, Jul.
2017.
[9] D. Binkley, M. Davis, D. Lawrie, J. I. Maletic, C. Morrell, and B. Sharif,“The impact of identiﬁer style on effort and comprehension,” Empir.
Softw. Eng., vol. 18, no. 2, pp. 219–276, Apr. 2013.
[10] A. Schankin, A. Berger, D. V. Holt, J. C. Hofmeister, T. Riedel, and
M. Beigl, “Descriptive compound identiﬁer names improve source code
comprehension,” in Proc. 26th Int. Conf. Program Comprehension,
May 2018, pp. 31–40.
[11] K. Tashima, H. Aman, S. Amasaki, T. Yokogawa, and M. Kawahara,“Fault-prone java method analysis focusing on pair of local variables
with confusing names,” in Proc. 44th Euromicro Conf. Softw. Eng. &Advanced App., Aug. 2018, pp. 154–158.
[12] H. Aman, S. Amasaki, T. Yokogawa, and M. Kawahara, “Empirical
study of fault introduction focusing on the similarity among local
variable names,” in Proc. 7th Int. Workshop Quantitative Approaches
to Softw. Quality, Dec. 2019, pp. 3–11.
[13] D. Gusﬁeld, Algorithms on Strings, Trees, and Sequences: Computer
Science and Computational Biology. Cambridge: Cambridge University
Press, 1997.
[14] T. Mikolov, K. Chen, G. Corrado, and J. Dean, “Efﬁcient estimation ofword representations in vector space,” CoRR, vol. abs/1301.3781, Sept.
2013.
[15] Q. V. Le and T. Mikolov, “Distributed representations of sentences anddocuments,” CoRR, vol. abs/1405.4053, May 2014.
[16] V. Arnaoudova, M. Di Penta, and G. Antoniol, “Linguistic antipatterns:
what they are and how developers perceive them,” Empir. Softw. Eng.,
vol. 21, no. 1, pp. 104–158, Feb. 2016.