Front.
 Comput. Sci., 2023, 17(6): 176214
https://doi.org/10.1007/s11704-022-2313-0
RESEARCH ARTICLE
Measuring code maintainability with deep neural networks
Yamin HU ( ✉)1, Hao JIANG2, Zongyao HU1
1   School of Computer Science and Technology, Beijing Institute of Technology, Beijing 100081, China
2   School of Artificial Intelligence, Anhui University, Hefei 230601, China
 Higher Education Press 2023
Abstract The maintainability of source code is a key quality
characteristic for software quality. Many approaches have been
proposed  to  quantitatively  measure  code  maintainability.  Such
approaches  rely  heavily  on  code  metrics,  e.g.,  the  number  of
Lines  of  Code  and  McCabe’s  Cyclomatic  Complexity.  The
employed code metrics are essentially statistics regarding code
elements,  e.g.,  the  numbers  of  tokens,  lines,  references,  and
branch  statements.  However,  natural  language  in  source  code,
especially  identifiers,  is  rarely  exploited  by  such  approaches.
As  a  result,  replacing  meaningful  identifiers  with  nonsense
tokens would not significantly influence their outputs, although
the  replacement  should  have  significantly  reduced  code
maintainability. To this end, in this paper, we propose a novel
approach  (called  DeepM)  to  measure  code  maintainability  by
exploiting the lexical semantics of text in source code. DeepM
leverages  deep  learning  techniques  (e.g.,  LSTM  and  attention
mechanism)  to  exploit  these  lexical  semantics  in  measuring
code  maintainability.  Another  key  rationale  of  DeepM  is  that
measuring  code  maintainability  is  complex  and  often  far
beyond  the  capabilities  of  statistics  or  simple  heuristics.
Consequently,  DeepM  leverages  deep  learning  techniques  to
automatically  select  useful  features  from  complex  and  lengthy
inputs and to construct a complex mapping (rather than simple
heuristics)  from  the  input  to  the  output  (code  maintainability
index).  DeepM  is  evaluated  on  a  manually-assessed  dataset.
The  evaluation  results  suggest  that  DeepM  is  accurate,  and  it
generates the same rankings of code maintainability as those of
experienced  programmers  on  87.5%  of  manually  ranked  pairs
of Java classes.
Keywords code  maintainability,  lexical  semantics,  deep
learning, neural networks
 1    Introduction
Software  maintenance  is  the  modification  of  a  software
product after delivery to fix bugs, to improve performance or
other  attributes,  or  to  adapt  the  involved  software  to  a  new
environment  [1,2].  Among  these  maintenance  activities,  21%
are corrective, 50% are perfective, 25% are adaptive, and 4%
are
   others  [3].  Notably,  software  maintenance  activities  are
Received May 25, 2022; accepted October 28, 2022
E-mail: ymhu@bit.edu.cn
inevitable  because  of  the  complexity  of  software  and  the
variability of requirements. The cost of software maintenance
is  high  and  up  to  67%  of  the  total  cost  during  the  software
development  life  cycle  [4].  Consequently,  software
maintenance is essential for continuous evolution of software.
Source code is the major artifact to modify during software
maintenance  process  [5].  In  the  international  standard
ISO/IEC  5055:2021  for  automated  source  code  quality
measures [6], code maintainability is defined as:
The capability of a product to be modified by the intended
maintainers with effectiveness and efficiency.
Code  maintainability  is  a  key  concern  for  maintainers.  To
make  the  modifications,  the  maintainers  must  first  read
(readability)  and  understand  (understandability)  the  source
code, then analyze (analyzability) the source code to find the
modification positions, and finally may reuse (reusability) the
existing  components  to  complete  the  modifications
(modifiability)  [7].  If  source  code  can  be  modified  by  the
intended  maintainers  with  fewer  efforts  to  successfully
complete software maintenance activities such as fixing bugs,
the  code  is  of  high  maintainability.  Code  maintainability  is
critical for measuring software maintainability and predicting
software  maintenance  cost.  Low-maintainability  code  would
result in that future maintainers (who may be not familiar with
the  considered  code)  would  spend  much  more  efforts  to
understand the code than the original developers, and thus the
cost of software maintenance will rise significantly [8].
Notably, code quality covers multiple aspects. The first and
foremost  aspect  is  the  functionality  and  performance  of  the
implementation (source code) with regard to its corresponding
requirements, i.e., the degree to which the source code works
as  expected  [9].  Another  key  aspect  of  code  quality  is  the
effectiveness  and  efficiency  with  which  the  maintainers
modify  the  source  code,  i.e.,  code  maintainability  [10].  The
second  aspect  (concerning  human  interpretation  and
modification of the source code) is often more subjective than
the first aspect (concerning the functionality and performance
of the source code); thus, the second aspect is more difficult to
quantify.
Many  approaches  have  been  proposed  to  quantitatively
measure the maintainability of source code. These approaches
usually  rely  heavily  on  code  metrics,  e.g.,  Lines  of  Code
(LOC) and McCabe’s Cyclomatic Complexity (MCC) [8,11].
2 Front. Comput. Sci., 2023, 17(6): 176214
The  widely  used  code  metric  is  Maintainability  Index  (MI)
[12],  which  computes  a  maintainability  index  rigorously
following a well-defined formula whose inputs include LOC,
MCC, Halstead Volume, and the percent of lines of comments
(optional). Heitlager et al. [13] proposed a hierarchical model
to  measure  a  system-level  maintainability  index  based  on  the
quality  model  defined  in  the  international  standard  ISO/IEC
9126-1  for  software  quality  models  [14].  The  maintainability
index is computed by taking a weighted average of the scores
of  four  quality  subcharacteristics  of  maintainability,  i.e.,
analyzability, changeability, stability, and testability; the score
of  each  subcharacteristic  is  computed  by  aggregating  the
scores  of  related  code  properties  (such  as  volume  and
complexity);  the  score  of  each  code  property  is  computed  by
aggregating  one  or  more  code  metrics,  e.g.,  LOC,  MCC,  and
the  number  of  assert  statements.  Al  Dallal  [8]  learned  a
logistic regression classifier that predicts whether a Java class
is modified heavily in terms of the number of revised lines of
code  during  software  evolution.  The  input  of  the  classifier  is
19 code metrics (such as LOC and the number of methods) for
three code properties: size, cohesion, and coupling.
Although  existing  approaches  to  measuring  code
maintainability  have  significantly  facilitated  the  quantitative
measurement  of  code  maintainability  [8,11,15],  the  resulting
maintainability  indexes  may  diverge  from  human  perception
[16–18].  Existing  approaches  to  measuring  code
maintainability  rely  heavily  on  code  metrics.  The  employed
code metrics are essentially statistics regarding code elements,
e.g.,  the  numbers  of  tokens,  lines,  references,  and  branch
statements. For example, LOC counts source code lines, MCC
counts  the  branch  statements,  CBO  (Coupling  Between
Objects) counts classes that are coupled to a given class, and
RFC  (Response  For  a  Class)  counts  unique  methods  invoked
in a class. Such code metrics and the approaches built on them
do  not  consider  the  semantics  of  the  natural  language,
especially  identifiers.  The  natural  language  contains  rich
semantic  information,  which  is  an  important  source  for
programmers  to  understand  the  business  logic  of  programs
[19].  Consequently,  such  natural  language  may  significantly
influence  the  quality  of  source  code,  especially  its
maintainability. For example, replacing meaningful identifiers
with  nonsense  tokens  would  significantly  reduce  the
maintainability of the source code. However, the replacement
may  not  significantly  influence  the  outputs  of  existing
approaches  because  the  replacement  does  not  significantly
change  the  underlying  code  metrics,  e.g.,  the  MCC,  CBO,  or
RFC.  An  example  is  presented  in  Listing 1−2.  Listing 1
presents method getTimeImpl from class java.util.Date in JDK
1.8,  which  normalizes  the  date  of  a  Date  object  if  necessary
and  returns  the  corresponding  milliseconds.  The  method  is
transformed  into  the  one  in  Listing 2  by  replacing  its
identifiers with nonsense tokens. The two codes have the same
numbers of tokens, lines, and branch statements. However, the
latter  is  much  harder  to  understand  and  maintain  than  the
former  because  of  the  nonsense  tokens.  As  a  result,  the
maintainability  indexes  produced  by  such  approaches
significantly  diverge  from  human  perception.  Notably,
although  some  textual  features  (e.g.,  the  number  of  identifier
 
 
 
terms  in  a  dictionary)  of  source  code  were  proposed  to
measure  code  readability  [20],  these  features  are  still
essentially statistics regarding text in source code.
To  this  end,  in  this  paper,  we  propose  a  novel  approach
called DeepM to quantitatively measure the maintainability of
source  code.  The  key  rationale  of  DeepM  is  that  the  lexical
semantics  of  identifiers  should  be  exploited  to  measure  code
maintainability. Identifiers account for approximately 70% of
source  code  (in  terms  of  characters)  [21]  and  serve  as  the
major  source  of  code  comprehension  [22].  However,  they
have  not  yet  been  exploited  by  existing  approaches  for
measuring  code  maintainability.  In  this  paper,  we  leverage
deep  learning  techniques  (i.e.,  word  embedding  [23],  LSTM
[24],  tree-LSTM  [25],  attention  mechanisms  [26],  and  dense
networks  [27])  to  exploit  the  lexical  semantics  of  identifiers
and to merge the resulting semantics, the structural features of
the source code, and the statistical features of the source code
into a single maintainability index.
In summary, our paper makes the following contributions:
●  A  deep  learning-based  approach  to  the  quantitative
measurement of code maintainability. To the best of our
knowledge,  this  is  the  first  approach  that  exploits  the
semantics  of  identifiers  for  code  maintainability
measurement.
● A public implementation of the proposed approach and
two  publicly  available  datasets  for  the  training  and
evaluation  of  code  maintainability  models.  The
implementation  and  datasets  are  publicly  available  at
github/DeepQuality/Deep_Maintainability.
●  An  initial  evaluation  of  the  proposed  approach.  The
evaluation  results  suggest  that  the  proposed  approach
outperforms  the  state-of-the-art  approaches,  improving
the  accuracy  of  the  results  from  75.0%  and  57.5%  to
87.5%.
The  rest  of  the  paper  is  structured  as  follows.  Section  2
introduces related work, Section 3 proposes the new approach,
 Yamin HU et al.    Measuring code maintainability with deep neural networks
Section  4  evaluates  the  approach,  Section  5  discusses  related
issues, and Section 6 concludes the paper.
 2    Related work
In  this  section,  we  present  the  related  work  on  code
maintainability  measurement.  The  existing  approaches  for
measuring  code  maintainability  usually  rely  heavily  on  code
metrics,  which  are  essentially  statistics  regarding  code
elements.  In  the  systematic  mapping  study  on  code  metrics
[28],  existing  code  metrics  are  divided  into  five  categories:
size,  complexity,  inheritance,  coupling,  and  cohesion.  These
code metrics are frequently used to measure different aspects
of  code  maintainability  of  object-oriented  programs.  For
example,  CBO  measure  modularity  [29]  and  reusability  [30];
RFC  measures  testability  [31],  LCOM  measures  modularity
[29],  WMC  measures  reusability  [30]  and  modifiability  [32].
In  addition,  some  code  metrics  were  specifically  proposed  to
measure  code  maintainability.  For  example,  Alzahrani  et  al.
[33]  defined  a  client-based  class  cohesion  metric  to  measure
class maintainability; the metric considers the ways that other
classes use the considered class.
Single metric only measures one aspect of source code such
as  complexity  and  thus  has  limitations  for  measuring  code
maintainability.  Consequently,  existing  approaches  leverage
multiple  code  metrics  to  measure  code  maintainability.
According  to  the  way  to  construct  mappings  between  code
metrics  and  maintainability  indexes,  these  approaches  can  be
divided  into  two  categories:  heuristic-based  approaches  and
machine learning-based approaches.
2.1    Heuristic-based approaches
Heuristic-based  approaches  are  implemented  based  on  well-
defined formulas, whose inputs are dozens of code metrics and
output  is  maintainability  indexes.  Notably,  the  forms  and
parameters  of  such  formulas  are  usually  determined  with  the
help  of  experts.  Oman  et  al.  [12]  proposed  the  metric  of
Maintainability  Index  (MI),  which  computes  maintainability
indexes  based  on  LOC,  MCC,  Halstead  Volume,  and  the
percent of lines of comments (optional). The higher the values
of  MI  are,  the  more  maintainable  the  corresponding  source
code should be. Maintainability Index is easy to compute, and
thus it has been widely used in industry. However, it still has
several  problems.  For  example,  it  is  easy  to  construct  a  low-
maintainability source code, which has the same values of the
three or four code metrics with another source code with high
maintainability;  thus,  both  the  code  have  the  same  value  of
MI, but they have significantly different maintainability.
In  addition,  some  approaches  employ  software  quality
models  to  construct  the  formulas  of  computing  code
maintainability  indexes.  For  example,  Heitlager  et  al.  [13]
employed  the  software  quality  model  defined  in  ISO/IEC
9126-1  (a  previous  standard  for  software  quality  models)  to
compute  a  system-level  maintainability  score.  The
maintainability  score  is  computed  by  taking  a  weighted
average of the scores of the four quality subcharacteristics of
maintainability (i.e., analyzability, changeability, stability, and
testability); the score of each subcharacteristic is computed by
aggregating  the  scores  of  related  code  properties  (such  as
volume  and  complexity);  the  score  of  each  code  property  is
3
computed by aggregating one or more code metrics.
These  heuristic-based  approaches  employ  well-defined
formulas as the mappings between the input source code and
the  maintainability  indexes,  and  the  parameters  in  the
mappings are determined manually [13] or calculated through
numerical  analysis  methods,  such  as  eigenvalue  extraction
[34]. However, such mappings result in significant limitations
for code maintainability measurement. Therefore, we propose
DeepM, which leverages deep neural networks to establish the
mappings.
2.2    Machine learning-based approaches
To establish complex mappings between the input source code
and  maintainability  indexes,  many  approaches  based  on
machine  learning  techniques  have  been  proposed  [8,15,35].
Malhotra  et  al.  [35]  conducted  an  empirical  study  for  class
maintainability  prediction  models.  They  compared  the
performance  of  28  techniques  for  constructing  mappings
between  extracted  code  metrics  from  Java  classes  and  code
maintainability  (i.e.,  high  or  low  maintainability),  e.g.,
AdaBoost,  k-Nearest  Neighbor,  Logistic  Regression  with
ridge estimator (noted as LRR), and CHC adaptive search for
instance  selection-based  k-nearest  neighbors  (noted  as  CHC).
In  their  experiments,  LRR  and  CHC  obtain  the  best
performance  in  terms  of  two  different  evaluation  metrics.  Al
Dallal  [8]  predicted  class  maintainability  using  various  code
metrics.  The  author  first  collected  source  files  from  three
open-source Java projects, including 1,099 Java classes, then,
constructed  a  dataset  that  contained  the  code  metrics  of  the
source  files  and  the  corresponding  labels  indicating  class
maintainability.  There  were  19  code  metrics  in  total,  which
covered  three  kinds  of  code  properties:  size,  cohesion,  and
coupling. The labels were two kinds of indirect maintainability
indicators:  the  number  of  revisions  in  which  the  class  was
changed, and the number of revised (add, delete, and change)
lines  of  code;  the  smaller  the  two  numbers  are,  the  more
maintainable  the  Java  classes  are.  Based  on  this  dataset,  the
authors  trained  a  multivariate  logistic  regression  model  to
predict the maintainability of the considered class.
These  machine  learning-based  approaches  and  heuristic-
based approaches rely heavily on code metrics. However, code
metrics  may  significantly  affect  code  maintainability
measurement for the following reasons. 1) Code metrics may
diverge  from  the  human  perception  of  code  maintainability
[16–18].  For  example,  decomposing  a  complex  method  into
multiple  smaller  ones  could  improve  code  maintainability,
because  it  makes  the  resulting  methods  have  small  and  clear
responsibilities  [17].  However,  such  decomposition  may
improve  the  value  of  code  metric  WMC  (Weighted  Methods
per Class) of the enclosing class (a larger WMC means higher
complexity),  which  is  the  sum  of  the  MCCs  of  its  methods
[17].  2)  Metrics-based  approaches  usually  rely  on  metric
thresholds  to  assess  code  maintainability;  however,  the
thresholds are hard to determine [36–38]. 3) It is challenging
to measure code maintainability, which is often far beyond the
abilities of simple code metrics. That is, such metrics may not
be sufficient for capturing the essence of code maintainability
because of the complexity of the input code. For example, the
composition  of  source  code  is  complex:  source  code  may
contain  various  code  elements,  such  as  comments,  methods,
4 Front. Comput. Sci., 2023, 17(6): 176214

and  statements,  and  there  are  complex  relationships  among in JDK 1.8. It is composed of two methods and two fields only

these  elements.  Most  importantly,  the  existing  approaches  do
not  consider  the  semantics  of  text  in  source  code.  However,
high-quality  identifiers  are  critical  for  code  maintainability.
DeepM  leverages  deep  learning  techniques  (rather  than
software  quality  models  and  traditional  machine  learning
techniques)  to  model  source  code  for  measuring  code
maintainability  and  simultaneously  exploits  the  lexical
semantics of identifiers in source code.
due  to  space  limitations.  The  class  Date  represents  a  specific
instant in time. The first method Date is a constructor, which
initializes  a  Date  object  using  a  number  representing  the
milliseconds  since  January  1,  1970,  00:00:00  GMT.  The
second  method  normalizes  the  date  of  a  Date  object  if
necessary and returns the corresponding milliseconds.
3.2    Lexical features

As  suggested  by  Fig. 1,  the  lexical  features  are  decomposed

  3    Approach
3.1    Overview
An overview of the proposed approach (DeepM) is presented
in  Fig. 1.  DeepM  takes  a  Java  class  as  input  and  generates  a
maintainability index for the given class. DeepM is composed
of  two  steps:  feature  extraction  and  deep  learning-based
into  three  categories:  identifiers,  field  declarations,  and
method headers. In the following subsections (Sections 3.2.1−
3.2.3), we explain in detail what they are, why they are useful,
and how they are extracted automatically.
3.2.1    Identifiers

prediction.  Feature  extraction  automatically  extracts  as  many Identifiers account for approximately 70% of the source code

features as possible related to code maintainability from a Java
class.  The  extracted  features  include  lexical  features  (i.e.,
identifiers,  field  declarations,  and  method  headers),  structural
features  (i.e.,  simplified  Abstract  Syntax  Trees  (ASTs)  and
structural  format),  and  traditional  code  metrics.  Lexical
features are exploited because the quality of natural language
in source code (especially in identifiers) represents how easily
programmers  can  understand  the  code,  i.e.,  code
understandability  (a  crucial  aspect  of  code  maintainability)
[22,39]. Structural features represent how well the source code
elements  are  formed  and  structured  and  thus  represent  code
in  terms  of  characters  [21]  and  contain  rich  semantics  [41].
The  semantics  are  crucial  for  code  understandability  [42].
Nonsense  identifiers  could  significantly  reduce  code
understandability;  in  this  case,  programmers  would  spend
much  more  time  and  effort  understanding  the  code  before
modifying  it.  For  example,  if  the  running  example  is
transformed by replacing its identifiers with nonsense ones (as
shown in Listing 4), the transformed version becomes hard to
understand  and  modify,  finally  resulting  in  low
maintainability.
 

readability  and  understandability  [40].  Traditional  code

metrics are statistics concerning different quality aspects, e.g.,
coupling, complexity, and cohesion. Such statistics have been
proven useful in measuring code maintainability [8].
Deep  learning-based  prediction  involves  estimating  the
maintainability of a given Java class according to the features
extracted  by  the  feature  extraction  step.  One  of  the  technical
challenges is that the features are diverse, including long word
sequences,  short  word  sequences,  large  trees,  floats,  and
integers. To handle such diverse inputs, we specifically design
different  neural  networks  to  preprocess  each  category  of
inputs  before  they  are  finally  merged  and  fed  into  a  dense
network.  The  output  of  the  final  dense  network  is  a  float
varying from zero to one to indicate the maintainability of the
given  Java  class,  where  one  indicates  the  highest
maintainability and zero indicates the lowest maintainability.
In the following subsections (Sections 3.2−3.5), we leverage
a  running  example  to  illustrate  how  the  proposed  approach
works.  The  running  example  is  presented  in  Listing 3.  The
class in Listing 3 is a simplified version of class java.util.Date  
 

 
 
Fig. 1    Overview of DeepM
 Yamin HU et al.    Measuring code maintainability with deep neural networks
To this end, identifiers within the source code are taken by
DeepM  as  the  first  lexical  feature  for  maintainability
measurement.  Identifiers  are  extracted  and  preprocessed  as
follows.
First, we retrieve all identifiers from the given Java class by
enumerating  all  SimpleName  nodes  with  the  well-known
JavaParser  [43].  Such  identifiers  are  represented  as  a
sequence according to their corresponding locations within the
document:
identi f iers = ⟨identi f ier1 , . . . , identi f iern ⟩, (1)
where identi f ieri is an identifier in the Java class.
For  the  running  example  in  Listing 3,  we  extract  the
following identifiers:
identi f iers = ⟨Date, f astT ime,
BaseCalendar, Date, cdate, Date,
date, f astT ime, date, getT imeImpl,
cdate, cdate, isNormalized,
normalize, f astT ime⟩. (2)
We notice that the same identifier may appear multiple times
within the identifier sequence. For example, the identifier date
appears twice within the running example (Lines 5 and 6). We
keep  such  repetitive  instances  because  the  frequencies  of
identifiers are useful clues regarding the importance (weights)
of  the  identifiers:  The  more  popular  the  identifier  is,  the
greater  influence  it  will  have  on  the  code  maintainability  of
the whole document.
Second,  each  of  the  identifiers  is  further  represented  as
follows:
 
identi f ieri = ⟨k, [so f tWord1 , so f tWord2 ,
. . . , so f tWordk ], idenT ype,
containingNumbers,
containingUnderscores,
containingDollars⟩, (3)
where  k  is the number of soft words split from the identifier.
so f tWordi   is  the  ith  soft  word.  idenT ype  is  the  type  of
identifier,  i.e.,  whether  it  is  a  class  name,  a  field  name,
a  method  name,  a  parameter  name,  or  a  variable
5
name.  containingNumbers ,  containingUnderscores,  and
containingDollars  indicate  whether  the  identifier  contains
numbers, underscores (_), and dollar signs (＄), respectively.
Notably,  following  Jiang’s  work  [44],  we  split  an  identifier
into  soft  words  based  on  capital  letters  and  division  markers,
including numbers, underscores, and dollar signs.
We represent the identifier  f astT ime on Line 2 in Listing 3
as follows:
 
f astT ime = ⟨2, [ f ast, T ime], “Field Name”,
f alse, f alse, f alse⟩. (4)
The expression suggests that the identifier is composed of two
soft words (i.e.,  f ast and  T ime), it is a field name, and it does
not contain any numbers, underscores, or dollar signs.
Third, we further refine each of the soft words as follows:
 
so f tWordi = ⟨text, position, isInDic,
f ormat⟩, (5)
where  text  is  a  sequence  of  characters  within  the  soft  word.
position indicates the sequence number of the soft word within
the  enclosing  identifier.  isInDic  indicates  whether  the  soft
word is an English dictionary word.  f ormat specifies the form
of  the  soft  word,  i.e.,  whether  all  letters  within  the  word  are
lowercase  (format=1),  all  but  the  first  letter  are  lowercase
(format=2),  all  letters  are  capitalized  (format=3),  or  none  of
the preceding forms are correct (format=4).
We  demonstrate  the  rationale  of  extracting  the  above
features  as  follows:  Regarding  isInDic,  identifiers  composed
of  dictionary  words  (instead  of  rare  character  sequences)
are  usually  more  readable  and  understandable  [45,46].
Regarding  containingNumbers ,  containingUnderscores,
containingDollars,  and  f ormat,  naming  conventions  make
programs more understandable through placing constraints on
the use of characters (i.e., numbers, underscores, dollar signs,
uppercase  letters,  and  lowercase  letters)  [47].  The  forms  of
well-named identifiers can reflect the functions of identifiers;
for  example,  the  forms  can  tell  whether  an  identifier  is  a
constant, which is helpful for understanding source code [47].
According to the general Java naming convention, class names
should  be  in  mixed  case  with  the  first  letter  of  each  token
capitalized;  programmers  should  not  use  dollar  signs  in  the
identifiers  of  their  own  code;  the  names  of  class  constants
should be all uppercase with tokens separated by underscores
[47].  Thus,  the  features  of  containingNumbers ,
containingUnderscores,  containingDollars,  and  f ormat
could  indicate  whether  identifiers  are  compliant  with  the
general  Java  naming  convention;  if  so,  the  identifiers  are
usually more readable and maintainable.
For the identifier  f astT ime on Line 2 in Listing 3, its final
representation is as follows:
f astT ime = ⟨2, [⟨“fast”, 1, true, 1⟩,
⟨“Time”, 2, true, 2⟩], “Field Name”,
f alse, f alse, f alse⟩
= [⟨2, “fast”, 1, true, 1, “Field Name”,
f alse, f alse, f alse⟩,
⟨2, “Time”, 2, true, 2, “Field Name”,
f alse, f alse, f alse⟩]. (6)
6 Front. Comput. Sci., 2023, 17(6): 176214
3.2.2    Field declarations
 
Fields  of  classes  represent  the  data/statues  of  the  enclosing
classes, and thus field names are critical for the interpretation
of  object  statuses.  Well-formed  fields  could  help  maintainers
quickly  understand  the  usages  of  the  field  variables.  For
example,  a  field  representing  a  constant  value  (declared  by
static  and  final)  should  be  named  in  uppercase  [48].  A  field
declaration  specifies  the  names,  access  modifiers,  and  data
types of the fields.
First, we retrieve all field declarations from a Java class:
f ieldDeclarations = ⟨ f ieldDeclaration1 , . . . ,
f ieldDeclarationn ⟩. (7)
Each of the resulting field declarations is further refined as:
f ieldDeclarationi =⟨k, [ f ield1 , f ield2 , . . . ,
f ieldk ], modi f ier,
isS tatic, hasComment⟩, (8)
where  k   is  the  number  of  fields  in  the  field  declaration.
Notably, a field declaration may declare more than one field.
For example, the following statement “public int a,b;” declares
two  fields  (i.e.,  a  and  b)  simultaneously.  modi f ier   specifies
the  accessibility  or  scope  of  a  field,  i.e.,  whether  the  field  is
public,  protected,  default,  or  private.  isS tatic  indicates
whether  the  field  declaration  contains  the  keyword  “static”.
hasComment  indicates  whether  the  field  declaration  is
associated with comments.
We  further  refine  each  of  the  declared  fields  in  Eq.  (8)  as
follows:
f ieldi = ⟨ f ieldName, isAssigned⟩, (9)
where  f ieldName  is  the  name  of  the  field  and  isAssigned
indicates whether the field is assigned explicitly.  f ieldName is
essentially  an  identifier,  and  thus,  it  is  further  refined
according to Eq. (3).
For the running example in Listing 3, the field declarations
are represented in Fig. 2.
3.2.3    Method headers
Methods  specify  the  behaviors  of  the  associated  class.
Although  methods  are  composed  of  method  headers  and
method  bodies,  maintainers  often  heavily  rely  on  method
headers to determine the behaviors of a class because lengthy
method bodies are often much more difficult to read than well-
formed  method  headers  [49].  Consequently,  the  quality  of
method  headers  may  significantly  influence  code
maintainability  (especially  code  reusability)  of  the  whole
class.  To  this  end,  we  take  method  headers  as  an  important
Fig. 2    Representation of the field declarations of running example
feature for code maintainability measurement.
First, we retrieve all method headers from a Java class:
 
methodHeaders = ⟨methodHeader1 , . . . ,
methodHeadern ⟩. (10)
Each  of  the  resulting  method  headers  is  further  refined  as
follows:
methodHeaderi = ⟨methodName, k,
[parameter1 , parameter2 ,
. . . , parameterk ],
modi f ier, isS tatic,
hasComment⟩. (11)
where  k   is  the  number  of  parameters  in  the  method  header.
methodName  and  parameteri  are  the  method  name  and  ith
parameter, respectively; they are further refined using Eq. (3).
modifier,  isStatic,  and  hasComment  are  the  same  as  those  in
Eq. (8) for field declarations.
3.3    Structural features
Compared  with  natural  language,  source  code  is  highly
structured,  and  the  structure  should  be  well  designed  [49].
Poorly formatted code (represented by the feature of structural
format)  would  significantly  reduce  code  readability  [50];  in
addition,  poorly  designed  source  code  (represented  by  the
feature of simplified ASTs) often results in strange structures,
e.g.,  deep  nests  and  numerous  repetitive  switches,  which
would  decrease  code  maintainability,  especially
understandability  [42].  Notably,  code  readability  and  code
understandability  are  two  crucial  aspects  for  code
maintainability.  To  this  end,  we  take  the  structures  of  Java
classes as important features for maintainability measurement.
3.3.1    Simplified ASTs
An  AST  is  a  tree  representation  of  the  syntactic  structure  of
source code. ASTs are widely used to represent the structures
of  source  code  [51].  Consequently,  we  retrieve  the  AST  for
each method within the given class. Each node of the AST tree
represents a source code element, e.g., a method declaration, a
variable, or a literal.
Notably, we leverage only the structure of the AST tree and
the  types  of  tree  nodes.  Other  information  embedded  in  the
tree, e.g., the identifiers and the values of literals, is ignored.
The  resulting  AST  tree  (excluding  ignored  information)  is
called a simplified AST.
3.3.2    Structural format
Although ASTs are widely used to represent the structures of
 Yamin HU et al.    Measuring code maintainability with deep neural networks
source  code,  they  ignore  the  coding  styles  and  formats  of
tokens. For example, indentation, successive white spaces, and
blank  lines  are  ignored  by  ASTs.  However,  such  formatting
information  is  critical  for  code  maintainability  because  well-
designed  source  code  with  a  poor  format  could  result  in  low
readability [52]. To this end, we leverage the structural format
of the source code as an important feature for maintainability
measurement.
To  represent  the  formatting  of  the  input  source  code,  we
take  the  source  code  as  plain  text  and  keep  all  special
characters,  e.g.,  white  spaces  and  line  breaks.  Notably,  we
replace  all  identifiers,  comments,  and  literals  within  the
source  code  with  constant  strings  “<IDENTIFIER>”,
“<COMMENT>”,  and  “<LITERAL>”,  respectively.  The
replacement  significantly  reduces  the  vocabulary  of  the
resulting features, i.e., the number of unique tokens appearing
in  the  extracted  features.  The  significantly  reduced
vocabulary,  in  turn,  facilitates  the  following  task  (neural
network-based  machine  learning)  because  smaller
vocabularies often result in shorter and more effective digital
representations of text [53].
3.4    Code metrics
Traditional  code  metrics  have  been  widely  used  to  measure
code maintainability [8,11,35]. To describe different concerns
regarding  code  maintainability,  various  code  metrics  have
been proposed [28], and the final overall maintainability index
is  often  a  synthesis  of  a  large  number  of  diverse  metrics
[8,11,35]. According to a systematic mapping study of source
code  metrics  [28],  existing  code  metrics  cover  the  following
concerns:  size,  complexity,  inheritance,  coupling,  and
cohesion. DeepM leverages metrics covering all of the above
concerns  except  for  inheritance  by  reusing  all  code  metrics
from  CK  [54,55]  except  for  those  related  to  inheritance.  An
overview  of  the  employed  metrics  is  presented  in  Table 1.
Notably, DeepM is fed with a single Java class document, and
thus,  it  is  difficult  to  discover  its  parents  without  additional
inputs (e.g., the enclosing Java project). Consequently, DeepM
does not leverage the inheritance of classes.
Table 1    Employed code metrics
Category Code metrics
Coupling Coupling between objects (CBO) response for a class (RFC)
Cohesion Lack of cohesion of methods (LCOM)
Complexity Weighted methods per class (WMC)
Size Lines of code (LOC)
Numbers of {anonymous, inner} classes
Numbers of {total, abstract, default, final, private, protected, public, static, synchronized, visible} methods
Numbers of {total, default, final, private, protected, public, static, synchronized} fields
Number of assignments
Number of log statements
Number of loops
Number of returns
Number of try/catches
Basic counting Number of comparisons
Number of lambdas
Number of math operations
Maximum number of nested blocks
Number of numbers
Number of parenthesized expressions
Number of string literals
Number of unique words
Number of variables
7
3.5    Deep learning-based quality prediction
Deep  learning  techniques  have  been  successfully  applied  to
resolve  various  software  engineering  tasks,  e.g.,  code
generation  [56],  code  completion  [57],  code  smell  detection
[19],  and  software  testing  [58].  One  of  the  significant
advantages of deep learning techniques is the ability to exploit
the deep semantics embedded in lengthy text [59]. To this end,
we  leverage  deep  learning  techniques  to  exploit  the  lexical
features  of  source  code.  Another  key  advantage  of  deep
learning  techniques  is  that  they  are  good  at  simulating
complex  mappings  from  inputs  to  outputs  [60].  Code
maintainability  is  a  complex  concept  concerning  diverse
aspects  of  the  input  code,  where  the  relations  among  such
aspects are hard to quantify. Consequently, the mappings from
the  code  features  to  maintainability  indexes  should  be  rather
complex. To this end, we leverage deep learning techniques to
automatically recover the complex mappings based on a large
set of training data.
Figure 3  presents  the  overview  of  the  deep  neural  network
for code maintainability measurement proposed in this paper.
The  network  takes  all  features  extracted  in  the  preceding
sections  (Sections  3.2−3.4).  The  output  maintainability  index
is a single float varying from zero to one, which indicates the
probability of the given Java class being maintainable (output
by the final sigmoid activation function) [61]. We specifically
design  deep  neural  networks  to  preprocess  each  category  of
input features. The features are diverse, containing long word
sequences,  short  word  sequences,  large  trees,  floats,  and
integers,  making  it  challenging  to  preprocess  them  with  a
universal network.
For text inputs, we employ the well-known word embedding
technique  [23]  to  transform  textual  tokens  into  fixed-length
numerical vectors. Because the length of the structural format
(extracted  in  Section  3.3.2)  varies  significantly  from  class  to
class,  we  leverage  LSTM  [24]  to  turn  such  variable-length
inputs  into  a  fixed-length  vector.  LSTM  is  a  special  kind  of
recurrent neural network that accepts variable-length inputs.
For  variable-length  inputs  where  the  order  of  elements  can
be ignored (e.g., the order of different field declarations), we
8 Front. Comput. Sci., 2023, 17(6): 176214

 
 
Fig. 3    Deep learning-based model for code maintainability measurement

leverage  attention-based  dense  networks  [26]  to  transform
them into fixed-length numeric vectors. Attention-based dense
networks  have  a  simplified  attention  mechanism,  which  is
proposed  to  solve  the  “addition”  and  “multiplication”
problems of long-term memory [26]. Notably, attention-based
dense  networks  request  a  customized  learnable  function  to
produce a probability vector. To this end, we employ a dense
network to simulate such functions (as presented in Fig. 4).
For  the  simplified  ASTs  (extracted  in  Section  3.3.1),  we
employ  a  variant  of  LSTM,  i.e.,  the  child-sum  tree-LSTM
[25],  to  learn  the  embeddings  of  the  nodes.  The  standard
LSTM  handles  sequential  data.  In  contrast,  tree-LSTM  is
specially  designed  to  handle  tree-structured  data  such  as
ASTs.  In  the  tree-LSTM,  a  unit  is  updated  according  to  the
current  input,  its  cell  state,  and  the  hidden  states  of  its
an  attention-based  dense  network  to  generate  the  vector
representing  identifiers.  Similarly,  we  can  get  the  vector
representing  field  declarations  and  the  vector  representing
method  headers.  For  simplified  ASTs,  the  nodes  of  each
simplified  AST  are  embedded  and  fed  into  a  tree-LSTM
network; then the outputs of the tree-LSTM network resulting
from multiple simplified ASTs are fed into an attention-based
neural  network.  For  structural  format,  the  internal  texts  are
embedded  and  fed  into  an  LSTM  network.  For  code  metrics,
the values of all metrics are fed into a dense network. Finally,
the  outputs  of  six  subnetworks  are  merged  and  fed  into  a
dense network with the activation function of sigmoid, and the
output of the dense network is the final maintainability index.
4    Evaluation

children.  In  a  bottom-up  manner,  the  hidden  state  of  the  root 4.1    Research questions
 

unit  is  finally  updated  and  serves  as  the  embedding  of  the
given AST.
The deep learning-based model works as follows. First, each
feature  is  fed  into  the  corresponding  subnetwork.  For
identifiers, their features are extracted according to Eq. (6); for
the features of each soft word in identifiers (corresponding to
an element of the array in Eq. (6)), the text of the soft word is
embedded  and  concatenated  to  other  corresponding  numeric
features;  and  then  the  resulting  vectors  (the  number  of  the
vectors is equal to the number of the soft words) are fed into
Our evaluation investigates the following research questions.
● RQ1: Is DeepM accurate, and to what extent can DeepM
outperform the state-of-the-art approaches in measuring
code maintainability?
● RQ2:  How  do  the  various  features  influence  the
performance of DeepM?
● RQ3: Is DeepM efficient and scalable?
RQ1  investigates  the  performance  of  DeepM  in  measuring
code  maintainability.  To  answer  RQ1,  according  to  the

 
 
Fig. 4    Attention-based dense network
 Yamin HU et al.    Measuring code maintainability with deep neural networks
empirical  study  on  class  maintainability  prediction  [35],  we
compare  DeepM  with  two  baseline  approaches:  logistic
regression  with  ridge  estimator  (noted  as  LRR)  and  CHC
adaptive  search  for  instance  selection-based  k-nearest
neighbors  (k-NN)  algorithm  (noted  as  CHC)  [35].  According
to the empirical study conducted by Malhotra et al. [35], they
are the best in predicting the maintainability of Java classes.
RQ2  investigates  the  importance  of  the  selected  features
with regard to the performance of DeepM. By answering RQ2,
we may know which features are more important than others.
RQ3  concerns  the  time  complexity  of  DeepM,  since  deep
learning-based  approaches  often  require  time-consuming
training  phases.  Investigating  RQ3  would  reveal  the
quantitative  time  required  by  the  training  phase  and  its
quantitative  relationship  with  the  size  of  the  training  data.
Answering  RQ3  would  also  reveal  whether  DeepM  can  be
efficiently applied to large-scale training data.
4.2    Dataset
To  evaluate  DeepM,  we  construct  two  datasets  (training  data
and testing data) as presented in Table 2. The second column
presents  the  sizes  of  the  datasets,  i.e.,  the  numbers  of  classes
involved  in  the  datasets.  The  last  column  specifies  how  the
datasets are constructed.
4.2.1    Testing data
The  testing  data  is  constructed  manually  to  guarantee  the
quality of the data. The construction is done as follows:
● First, we select five Java projects from GitHub: Tomcat,
Log4j  2,  Apollo,  Druid,  and  Sentinel.  The  projects  are
selected for the following reasons. First, all of them are
well-known,  high-quality  projects  with  long  and
successful  evolution  histories.  Second,  these  projects
cover different domains: Tomcat is a web server, Log4j
2  is  a  logging  utility,  Apollo  is  a  configuration
management  system,  Druid  is  a  database  connection
pool, and Sentinel is a flow control component.
●  Second,  from  each  of  the  five  projects,  we  randomly
select  80  classes  and  distribute  them  into  40  groups
(pairs),  where  each  group  is  composed  of  exactly  two
classes. Three programmers (with at least five years of
experience)  rank  the  maintainability  of  each  pair
according  to  their  maintenance  experience  and  the
requirements  for  code  maintainability,  especially  code
readability,  understandability,  and  modifiability;
notably,  the  programmers  have  learned  the  definitions
of  code  maintainability  and  related  quality
characteristics  of  code  maintainability  before  labeling
the  data.  If  they  reach  agreement,  we  keep  the  pair  in
the  testing  data;  otherwise,  the  pair  is  dropped.  If  the
latter  occurs,  we  randomly  reselect  two  different
classes,  and  the  three  programmers  rank  their
Table 2    Datasets for evaluation
Dataset # Classes Construction approach
Testing data 400 Manual Construction
Training data
1,394,514 Automated Construction
9
maintainability;  we  repeat  this  step  until  agreement  is
reached.
4.2.2    Training data
Ideally, we should have constructed training data in the same
way as we construct the testing data to guarantee the quality of
the resulting data. However, manual constructing as we do in
Section  4.2.1  is  time-consuming,  making  it  challenging  to
construct  large-scale  training  data.  Notably,  the  proposed
approach leverages a deep neural network that requests a large
amount  of  training  data.  Consequently,  we  automatically
construct a large-scale training dataset as follows:
● First, we select high-quality Java projects from GitHub.
Each of the selected projects should 1) have more than
500  stars;  2)  have  more  than  30  contributors;  3)  have
more  than  300  closed  pull  requests;  4)  have  a
significant  part  (no  less  than  8%)  of  the  closed  pull
requests  already  reviewed.  Notably,  the  criteria  are
empirically  designed  according  to  our  experience  in
open source applications [62,63]: 1) These projects are
continuously  maintained  by  active  communities  in
which many experienced programmers contribute to the
projects.  2)  These  projects  have  specific  code  quality
criteria  demonstrated  in  the  document  of  contribution
guidelines. 3) The committed code is usually reviewed
before  merging  them  into  the  code  repositories.
Consequently,  the  source  code  in  these  projects  is
usually of high maintainability. The selection results in
378 projects noted as high-quality projects.
● Second,  we  select  low-quality  Java  projects  from
GitHub. Each of the selected projects should 1) have no
star;  2)  have  fewer  than  5  contributors;  3)  have  fewer
than  5  closed  pull  requests;  4)  have  no  closed  pull
requests that have already been reviewed. The selection
results in 54,882 projects, noted as low-quality projects.
●  Third,  we  retrieve  the  Java  classes  from  the  selected
projects. We also label all classes from the high-quality
projects  as  good  (of  high  maintainability)  and  those
from  the  low-quality  projects  as  bad  (of  low
maintainability).
●  Finally,  we  apply  simple  random  sampling  to  exclude
potential  confounding  variables.  Notably,  the  high-
maintainability  classes  collected  in  the  preceding  steps
are  usually  lengthier  than  the  poor  classes.
Consequently, if we take all of the collected classes as
training  data  to  train  the  proposed  model,  the  sizes  of
such  classes  could  serve  as  a  significant  confounding
variable [64]. Thus, for each possible LOC, we separate
the classes with the LOC into a high-maintainability set
and a low-maintainability set and randomly drop classes
in the larger set to make the two sets equal in size. The
resulting  dataset  is  composed  of  697,257  high-
maintainability classes and 697,257 low-maintainability
classes.
4.3    Process
To  answer  RQ1,  we  evaluate  DeepM,  and  two  baseline
approaches, i.e., LRR and CHC, through the following steps:
10 Front. Comput. Sci., 2023, 17(6): 176214
●  First,  the  training  data  is  partitioned  randomly  into  the
training part (96%), and the validation part (4%).
● Second, DeepM and the baseline approaches are trained
independently  on  the  training  part  and  fine-tuned  with
the validation part.
● Third, DeepM and the baseline approaches are evaluated
with the testing data.
Suitable  hyper-parameter  configurations  are  crucial  for
DeepM  to  measure  code  maintainability.  However,  the
training  of  DeepM  requires  lots  of  time  (~62  hours),  which
results  in  that  we  cannot  test  many  combinations  of  hyper-
parameters.  Consequently,  we  first  identify  several  typical
configurations  [65]  to  train  DeepM,  and  observe  the
performance on the validation data. Subsequently, we try other
configurations according to the heuristics in [65] to find better
hyper-parameter configurations.
We demonstrate the final hyper-parameter configurations as
follows.  We  train  DeepM  using  the  Adam  optimizer  for  3
epochs  with  the  learning  rate  of  0.001,  the  batch  size  of  32,
and  the  loss  function  of  binary  cross  entropy.  Regarding  the
structure  of  our  network,  the  attention-based  dense  networks
are  3-layer  networks  (16-8-1)  with  the  ELU  activation
function. The dense network for the feature of code metrics is
also  a  3-layer  network  (32-16-8)  with  the  ELU  activation
function.  The  LSTM  is  a  single-layer  network  with  32  units
and  8-dimensional  embedding  of  the  input  text.  The  tree-
LSTM  is  a  single-layer  network  with  8-dimensional
embedding  of  both  the  simplified  AST  nodes  and  the  final
representations. The final dense network is a 4-layer network
(32-16-8-1)  with  the  ELU  activation  function  for  the  front
layers  and  the  sigmoid  activation  function  for  the  last  layer.
The  sizes  of  vocabularies  for  soft  words,  simplified  AST
nodes, and texts in structural format are 56949 (covering 99%
of all soft words), 591 (all simplified AST nodes), and 110 (all
texts in structural format) respectively.
For the baseline approach CHC, the original implementation
(in  KEEL)  employs  1-nearest  neighbor  (1-NN)  algorithm  to
classify  unseen  instances  based  on  selected  instances.  To
compute  maintainability  indexes,  we  modify  the  1-NN  to  7-
NN  (optimal  in  terms  of  the  accuracy  regarding  RQ1).  For
other parameters of the two baseline approaches, we take the
same configurations as [35].
During  the  testing  process,  the  compared  approaches  are
employed  to  rank  each  class  pair  in  the  testing  data  that  is
composed  of  a  low-maintainability  class  and  a  high-
maintainability  class.  If  the  maintainability  index  generated
for  the  high-maintainability  class  is  greater  than  that  of  the
low-maintainability  class,  the  ranking  of  the  two  classes  is
deemed  correct.  Otherwise,  the  ranking  is  incorrect.  The
performance  of  the  evaluated  approaches  in  ranking  the
classes is computed as follows:
Table 3    Ranking accuracy on the testing data
Approach Tomcat Log4j 2
DeepM 90.0% 80.0%
LRR 80.0% 70.0%
CHC 65.0% 55.0%
#class pairs ranked correctly
RankingAccuracy = . (12)
#generated class pairs
To  investigate  the  importance  of  different  features  (RQ2),
we conduct an ablation study [66], which is a frequently used
method  to  understand  the  reasons  for  the  success  of  neural
network-based models. Each time, we disable a single feature
and  repeat  the  evaluation  to  investigate  how  the  performance
of DeepM changes.
4.4    RQ1: DeepM Outperforms the Baseline Approaches
To  answer  RQ1,  we  compare  DeepM  with  two  baseline
approaches  in  terms  of  measuring  code  maintainability.  We
present  the  evaluation  results  in  Table 3,  and  make  the
following observations:
●  First,  DeepM  is  accurate  with  respect  to  ranking  class
pairs.  In  most  cases  (87.5%),  DeepM  generates  the
correct  rankings.  The  accuracies  on  the  five  projects
vary  from  80.0%  to  92.5%,  which  demonstrates  the
effectiveness of DeepM.
●  Second,  DeepM  significantly  outperforms  the  two
baseline approaches, i.e., LRR and CHC. On all the five
projects,  DeepM  generates  higher  accuracies  than  both
the  two  baseline  approaches.  It  improves  the  average
RankingAccuracy  from  75.0%  for  LRR  and  57.5%  for
CHC  to  87.5%,  where  the  improvements  are  12.5  and
30.0 percentage points, respectively.
●  Finally,  it  is  challenging  for  LRR  and  CHC  for
measuring  code  maintainability:  The  average
RankingAccuracy  are  low,  i.e.,  75.0%  for  LRR  and
57.5% for CHC. This demonstrates that measuring code
maintainability is far beyond the abilities of simple code
metrics.
To further reveal the reasons for the success of DeepM, we
retrieve all the 27 (27/200 = 13.5%) class pairs of the testing
data  for  which  the  two  baseline  approaches’  rankings  are
incorrect but DeepM’s rankings are correct, and then analyze
the  resulting  classes  from  multiple  aspects  such  as  identifier
semantics,  logical  complexity,  and  code  style.  We  find  that
one  of  the  major  reasons  for  the  success  of  DeepM  is  that  it
takes  full  advantage  of  the  natural  language  in  identifiers.
DeepM correctly ranks 25 (25/27 = 92.6%) class pairs because
it exploits the feature of identifiers: forms (length, abbreviated
or full form, and letter case) and semantics. An example from
Apollo  project  is  Java  class  ConfigChangeEvent.  The  metrics
of  this  Java  class,  e.g.,  CBO,  WMC,  RFC,  and  LCOM,  are
reasonable  and  comparable  to  those  of  the  high-
maintainability classes within the training data. Consequently,
the  two  baseline  approaches  predict  this  class  as  higher
maintainability  (than  the  other  class  in  the  same  class  pair).
However, the identifiers within this class are poorly designed.
Apollo Druid Sentinel Average
90.0% 85.0% 92.5% 87.5%
77.5% 75.0% 72.5% 75.0%
70.0% 45.0% 52.5% 57.5%
 Yamin HU et al.    Measuring code maintainability with deep neural networks
The first issue with the identifiers within this class is the form
of  the  method  name  changedKeys.  Programmers  usually
leverage verb phrases to name methods [67], and noun phrases
(such  as  the  name  changedKeys)  are  rarely  employed  as
method names. The second issue is the low readability of the
identifiers because of containing nonsense tokens and hard-to-
interpret  abbreviations  such  as  “m_changes”.  Thus,  DeepM
suggests that it is a lower-maintainability class.
Seven (3.5% = 7/200) class pairs are incorrectly ranked by
DeepM  but  correctly  ranked  by  both  the  two  baseline
approaches. We analyze the seven classes (like we do above)
and find that the reasons for misprediction might be that many
identifiers  within  these  classes  are  very  descriptive.  An
example from Tomcat project is Java class JspPropertyGroup,
which  is  of  lower  maintainability  in  the  enclosing  class  pair;
however,  DeepM  suggests  that  the  class  is  of  higher
maintainability. Many issues result in the class being of lower
maintainability.  For  example,  the  boolean  variable
deferredSyntax  should  be  named  as  isDeferredSyatax  instead
of the noun phrase [68]; the field urlPattern should be named
as urlPatterns because it is a collection variable with the type
of  LinkedHashSet<String>  [68].  From  the  example,  we  can
conclude that measuring code maintainability is complex, and
the  word  embedding  technique  may  be  not  sufficient  enough
for  exploiting  the  semantics  of  identifiers  to  measure  code
maintainability.  In  the  future,  we  will  leverage  other
techniques to model the semantics in source code.
4.5    RQ2: All exploited features are helpful
 
To  investigate  the  importance  of  the  exploited  features,  we
conduct  an  ablation  study  [66]  on  the  testing  data.  The
evaluation results are presented in Table 4. From the table, we
make the following observations:
●  First,  all  exploited  features  are  helpful.  Disabling  any
feature  results  in  large  reductions  with  respect  to  the
average  RankingAccuracy.  The  reduction  rates  vary
from 2.9% to 15.4% (last column in Table 4).
●  Second,  identifiers  contribute  most  to  the  ability  of
DeepM  to  measure  code  maintainability.  Disabling
identifiers results in the largest reduction with respect to
the  average  RankingAccuracy,  i.e.,  a  reduction  rate  of
up  to  15.4%.  In  addition,  for  each  of  the  five
applications, disabling identifiers has the largest impact
on  the  performance  of  DeepM.  Consequently,  we  can
conclude  that  identifiers  are  important  for  code
maintainability measurement.
Table 4    Effects of the exploited features on the testing data (ranking accuracy)
Setting Tomcat Log4j 2 Apollo
Default 90.0% 80.0% 90.0%
Disabling identifiers 75.0% 60.0% 80.0%
Disabling field declarations 80.0% 82.5% 90.0%
Disabling method headers 80.0% 75.0% 90.0%
Disabling simplified ASTs 85.0% 70.0% 87.5%
Disabling structural format 82.5% 67.5% 90.0%
Disabling code metrics 80.0% 67.5% 87.5%
11
●  Third,  disabling  field  declarations  results  in  less
reduction  than  that  yielded  by  disabling  other  features
with  respect  to  the  average  RankingAccuracy,  i.e.,  a
reduction  rate  of  2.9%.  The  reasons  for  this  are
probably  as  follows:  1)  The  features  of  field
declarations  contain  only  static  information  (without
dynamic behaviors) about the enclosing classes. 2) The
semantics contained in field declarations are covered by
the features of identifiers.
4.6    RQ3: DeepM is efficient
To investigate the efficiency of DeepM, during the evaluation
specified  in  Section  4.3,  we  record  the  time  consumed  by  its
training  and  testing  processes.  Notably,  the  training  and
testing procedures are conducted on a workstation with a GPU
whose settings are listed as follows: 128 GB of RAM, Intel(R)
Xeon(R) E5-2620 v4 CPU, and NVIDIA TITAN RTX GPU.
The evaluation results are shown in Table 5.
From  the  table,  we  observe  that  the  training  phase  can  be
accomplished  within  62  hours  (3  epochs)  on  a  single
workstation, although the training data (containing 85,560,826
lines  of  code)  is  massive.  We  also  notice  that  DeepM  is
efficient in generating maintainability indexes. It takes DeepM
only  0.076  seconds  on  average  to  predict  the  maintainability
index  for  a  single  class.  Notably,  “Training  Time”,  “Testing
Time”,  and  “Testing  Time  per  Class”  include  the  time
required for feature extraction.
Figure 5  further  investigates  how  the  size  of  the  training
dataset  influences  the  training  time.  From  this  figure,  we
observe that there is a linear relationship between the training
time and the size of the training dataset. Consequently, DeepM
can be efficiently applied to large-scale training data.
4.7    Threats to validity
A  threat  to  constructive  validity  is  that  the  maintainability
labels  and  maintainability  rankings  of  the  classes  in  the
training data and the testing data may be inaccurate. To collect
labeled data for training and testing, we collect a large number
of  Java  projects  from  GitHub  and  label  the  maintainability
indexes of the Java classes within such projects automatically
according  to  some  project-level  metrics,  e.g.,  the  number  of
stars associated with the projects. However, there is no strong
and  quantitative  evidence  that  such  employed  metrics  can
accurately  distinguish  high-quality  projects  from  low-quality
projects.  Furthermore,  not  all  classes  from  high-quality  (low-
quality)  projects  are  of  high  (low)  maintainability.  To  reduce
the  threat  level,  three  programmers  label  100  randomly-
Druid Sentinel Average ↓ Rate
85.0% 92.5% 87.5%
72.5% 82.5% 74.0% 15.4%
80.0% 92.5% 85.0% 2.9%
85.0% 90.0% 84.0% 4.0%
82.5% 92.5% 83.5% 4.6%
80.0% 92.5% 82.5% 5.7%
80.0% 92.5% 81.5% 6.9%
12 Front. Comput. Sci., 2023, 17(6): 176214
Table 5    Performance of DeepM
Metric Value
Size of training data 85,560,826 LOC
Training time (3 epoch) ~62 hours
Size of testing data 29,434 LOC
Testing time ~30 seconds
Testing time per class ~0.076 seconds
 
Fig. 5    Training time versus size of training dataset
sampled,  high-maintainability  classes  and  100  low-
maintainability  classes  according  to  their  maintenance
experiences;  the  programmers  have  at  least  five  years  of
experience  developing  or  maintaining  large  commercial
applications using Java language. The results suggest that 189
out of the 200 classes are labeled correctly (The programmers
reach  agreement  and  the  labels  are  correct).  In  addition,  we
manually create another dataset (called testing data), where the
classes  are  ranked  manually  by  the  three  experienced
programmers.  Notably,  manual  labeling  is  not  guaranteed  to
be  correct  because  maintainability  is  essentially  subjective.
The three experienced programmers rank class pairs from the
same high-quality projects together. The class pairs are put in
the testing data only when the programmers reach agreement.
Another  threat  related  to  the  datasets  is  that  DeepM  is
trained  with  the  datasets  with  the  labels  of  high  or  low
maintainability  instead  of  the  labels  of  floating  numbers
between  0  and  1  indicating  code  maintainability.  Ideally,  a
large  dataset  with  fine-grained  labels  (i.e.,  floating  numbers
between  0  and  1)  should  be  constructed  to  train  DeepM.
However,  it  is  hard  to  obtain  fine-grained  maintainability
indexes  of  lots  of  class  files:  (1)  We  have  tried  our  best  to
automatically  construct  such  a  dataset  according  to  the
information  on  refactoring  and  code  reviews  in  code
repositories, but we cannot obtain fine-grained maintainability
indexes especially for lots of class files; (2) Manually labeling
the  maintainability  indexes  of  lots  of  class  files  is  infeasible.
Consequently,  we  construct  the  training  data  through  the
heuristic strategy to train our neural network-based model. To
reduce  the  threat  level,  we  use  the  manually  labeled  testing
data to evaluate the effectiveness of DeepM; ranking the class
pairs of the testing data is more challenging than classifying a
class file as high or low maintainability.
A  threat  to  internal  validity  is  that  the  original
implementations  of  the  baseline  approaches,  i.e.,  logistic
regression  with  ridge  estimator  (noted  as  LRR)  and  CHC
adaptive  search  for  instance  selection-based  k-nearest
neighbors  algorithm  (noted  as  CHC),  cannot  output  a  float
number indicating code maintainability; thus, we modify them
for  evaluation  purposes.  In  the  empirical  study  on  class
maintainability  [35],  Malhotra  et  al.  constructed  class
maintainability  prediction  models  using  the  Knowledge
Extraction based on Evolutionary Learning (KEEL) tool [69].
Consequently,  we  modify  the  two  implementations  in  KEEL
to  obtain  code  maintainability  indexes,  i.e.,  a  float  number
varying  from  zero  to  one:  1)  For  LRR,  the  implementation
itself (in KEEL) has a variable whose values vary from zero to
one indicating code maintainability; thus, we output the values
to  result  files  for  evaluation  purposes.  2)  For  CHC,  the
implementation  (in  KEEL)  employs  1-nearest  neighbor  (1-
NN) algorithm to classify unseen instances based on selected
instances; we modify the 1-NN to k-NN, thus we can compute
maintainability  indexes.  The  experimental  results  in  RQ1  are
obtained using the 7-NN model, which is optimal in terms of
accuracy. In addition, CHC is so slow that it cannot be trained
on the entire training data (1,338,733 Java classes) even if we
optimize it through parallel streams in Java and run it on a 32-
core  workstation.  Consequently,  we  train  CHC  on  randomly-
sampled  100,000  Java  classes  from  the  training  data,  and
report  corresponding  experimental  results  in  RQ1.  Notably,
the  size  of  the  sampled  dataset  (i.e,  100,000)  is  enough  for
training  CHC,  because  the  difference  between  the  accuracy
obtained on 100,000 Java classes and that obtained on 50,000
Java  classes  is  less  than  1%.  However,  the  reimplementation
could  be  buggy,  which  may  influence  the  conclusions  drawn
about the baseline approaches. We also make the modification
publicly  available  as  a  part  of  the  replication  package
(available at github/DeepQuality/Deep_Maintainability).
A  threat  to  external  validity  is  that  the  datasets,  especially
the  manually  constructed  dataset,  are  small.  Some  special
characteristics  of  such  data  may  bias  the  evaluation,  and  the
obtained  conclusions  may  not  hold  on  other  data.  To  reduce
the  threat  level,  we  sample  Java  classes  from  diversified
projects that come from different domains and were developed
by different developers/companies.
 5    Limitations
The proposed approach is currently confined to a single source
file, i.e., a Java class. It is challenging to extend our approach
to project-level code maintainability measurement because of
the  inefficiency  of  deep  neural  networks  in  handling  lengthy
text.  A  project  in  the  industry  usually  contains  thousands  of
Java  classes  where  such  classes  are  connected  with  complex
semantic  and  syntactic  correlations.  Feeding  all  such  tokens
and  their  relations  into  a  single  network  could  result  in
extremely large neural work containing billions of parameters.
However,  tuning  such  parameters  may  request  numerous
labeled  data  that  we  cannot  offer.  Notably,  the  average
maintainability  index  of  the  classes  within  a  project  (called
average  index  for  short)  alone  is  insufficient  to  reveal  the
maintainability  of  the  whole  project  because  it  ignores  some
correlations (e.g., inheritance) among the classes.
It is also difficult to apply DeepM to code commits. A code
 Yamin HU et al.    Measuring code maintainability with deep neural networks
commit  represents  changes  to  a  project  for  a  specific
programming task, e.g., fixing a bug. Although code commits
are  often  small,  they  could  reach  multiple  Java  files.  As  a
result,  DeepM  could  not  be  applied  to  such  code  commits.
Furthermore,  code  commits  focus  on  the  local  design  of
source  code  (e.g.,  a  single  line  of  source  code)  whereas
DeepM  focuses  on  the  overall  maintainability  of  classes.
Consequently,  we  cannot  apply  DeepM  to  code  commits
without significant adaption.
Due to the nature of deep learning-based models, the outputs
of  DeepM  cannot  directly  help  programmers  improve  the
maintainability  of  their  code.  However,  DeepM  has  other
usages. For example, when automatic refactoring is applied to
improve  code  maintainability,  DeepM  can  check  whether  the
post-refactoring class is of high maintainability automatically,
and  then  accept  or  reject  the  refactoring.  In  addition,  DeepM
could  check  whether  each  changed  class  in  commits  satisfies
maintainability  requirements  before  merging  them,  and  thus
make the repository in a maintainable state.
Finally,  the  current  implementation  of  the  proposed
approach  is  confined  to  Java.  Java  is  selected  because  of  its
popularity [70]. However, our approach does not make use of
any  Java-specific  features.  Consequently,  it  may  have  the
ability  to  be  extended  to  other  object-oriented  programming
languages,  such  as  C++.  In  the  future,  we  should  investigate
how well it works on other programming languages.
 6    Conclusions
The maintainability of source code is one of the key concerns
in  software  maintenance.  However,  the  existing  approaches
for  measuring  code  maintainability  rely  heavily  on  code
metrics, and the quality of the natural language within source
code  is  ignored.  Consequently,  in  this  paper,  we  propose  a
deep learning-based approach called DeepM to quantitatively
measure the maintainability of Java classes. DeepM leverages
deep learning techniques to exploit the lexical semantics of the
natural language (especially identifiers) in source code and to
build mappings from the resulting lexical semantics, as well as
structural  features  and  traditional  code  metrics,  to
maintainability  indexes.  DeepM  is  evaluated  on  manually-
assessed  source  code,  and  our  evaluation  results  suggest  that
DeepM  is  accurate  and  generates  the  same  rankings  of  code
maintainability  as  those  of  experienced  programmers  on
87.5% of manually ranked pairs of Java classes.
In  the  future,  we  would  like  to  extend  the  proposed
approach  to  other  object-oriented  programming  languages,
such  as  C++.  It  would  also  be  interesting  to  investigate  the
potential of the proposed approach regarding the evaluation of
larger  elements,  e.g.,  packages,  modules,  subsystems,  and
even whole systems.
References
1. Schneidewind  N  F.  The  state  of  software  maintenance.  IEEE
Transactions on Software Engineering, 1987, SE-13(3): 303–310
2. Bennett  K  H,  Rajlich  V  T.  Software  maintenance  and  evolution:  a
roadmap. In: Proceedings of the Conference on the Future of Software
Engineering. 2000, 73−87
3. Lientz B P, Swanson E B. Software Maintenance Management: A Study
 
13
of  the  Maintenance  of  Computer  Application  Software  in  487  Data
Processing Organizations. Reading: Addison-Wesley, 1980
4. Yau  S  S,  Collofello  J  S.  Some  stability  measures  for  software
maintenance.  IEEE  Transactions  on  Software  Engineering,  1980,  SE-
6(6): 545–552
5. Reiss  S  P.  Incremental  maintenance  of  software  artifacts.  IEEE
Transactions on Software Engineering, 2006, 32(9): 682–697
6. ISO.  ISO/IEC  5055:  2021  Information  technology  —  Software
measurement  —  Software  quality  measurement  —  Automated  source
code quality measures. Geneva: ISO, 2021
7. Grubb  P,  Takang  A  A.  Software  Maintenance:  Concepts  and  Practice.
2nd ed. London: World Scientific Publishing, 2003
8. Al  Dallal  J.  Object-oriented  class  maintainability  prediction  using
internal quality attributes. Information and Software Technology, 2013,
55(11): 2028–2048
9. Myers  G  J,  Badgett  T,  Thomas  T  M,  Sandler  C.  The  Art  of  Software
Testing. 2nd ed. Hoboken: John Wiley & Sons, 2004
10. Mari  M,  Eila  N.  The  impact  of  maintainability  on  component-based
software  systems.  In:  Proceedings  of  the  29th  Euromicro  Conference.
2003, 25−32
11. Li  W,  Henry  S.  Object-oriented  metrics  that  predict  maintainability.
Journal of Systems and Software, 1993, 23(2): 111–122
12. Oman  P,  Hagemeister  J.  Construction  and  testing  of  polynomials
predicting  software  maintainability.  Journal  of  Systems  and  Software,
1994, 24(3): 251–266
13. Heitlager  I,  Kuipers  T,  Visser  J.  A  practical  model  for  measuring
maintainability. In: Proceedings of the 6th International Conference on
the Quality of Information and Communications Technology (QUATIC
2007). 2007, 30−39
14. ISO. ISO/IEC 9126-1: 2001 Software engineering—Product quality —
Part 1: Quality model. Geneva: ISO, 2001
15. Zhou  Y,  Leung  H.  Predicting  object-oriented  software  maintainability
 
using  multivariate  adaptive  regression  splines.  Journal  of  Systems  and
Software, 2007, 80(8): 1349–1361
16. Bavota G, Dit B, Oliveto R, Di Penta M, Poshyvanyk D, De Lucia A.
An empirical study on the developers’ perception of software coupling.
In:  Proceedings  of  the  35th  International  Conference  on  Software
Engineering (ICSE). 2013, 692−701
17. Pantiuchina  J,  Lanza  M,  Bavota  G.  Improving  code:  the  (Mis)
perception  of  quality  metrics.  In:  Proceedings  of  2018  IEEE
International  Conference  on  Software  Maintenance  and  Evolution
(ICSME). 2018, 80−91
18. Lenhard J, Blom M, Herold S. Exploring the suitability of source code
metrics  for  indicating  architectural  inconsistencies.  Software  Quality
Journal, 2019, 27(1): 241–274
19. Liu  H,  Xu  Z,  Zou  Y.  Deep  learning  based  feature  envy  detection.  In:
Proceedings  of  the  33rd  ACM/IEEE  International  Conference  on
Automated Software Engineering. 2018, 385−396
20. Scalabrino S, Linares-Vasquez M, Poshyvanyk D, Oliveto R. Improving
code  readability  models  with  textual  features.  In:  Proceedings  of  the
24th IEEE International Conference on Program Comprehension. 2016,
1−10
21. Kim S, Kim D. Automatic identifier inconsistency detection using code
dictionary. Empirical Software Engineering, 2016, 21(2): 565–604
22. Schankin  A,  Berger  A,  Holt  D  V,  Hofmeister  J  C,  Riedel  T,  Beigl  M.
Descriptive  compound  identifier  names  improve  source  code
comprehension.  In:  Proceedings  of  the  26th  IEEE/ACM  International
Conference on Program Comprehension (ICPC). 2018, 31−40
23. Lai S, Liu K, He S, Zhao J. How to generate a good word embedding.
IEEE Intelligent Systems, 2016, 31(6): 5–14
24. Greff K, Srivastava R K, Koutník J, Steunebrink B R, Schmidhuber J.
LSTM: a search space odyssey. IEEE Transactions on Neural Networks
and Learning Systems, 2017, 28(10): 2222–2232
25. Tai  K  S,  Socher  R,  Manning  C  D.  Improved  semantic  representations
from tree-structured long short-term memory networks. In: Proceedings
of  the  53rd  Annual  Meeting  of  the  Association  for  Computational
Linguistics  and  the  7th  International  Joint  Conference  on  Natural
14 Front. Comput. Sci., 2023, 17(6): 176214

Language Processing (Volume 1: Long Papers). 2015, 1556−1566 47. ORACLE. Naming Conventions. See oracle-base/articles/misc/naming-

 

26. Raffel  C,  Ellis  D  P.  Feed-forward  networks  with  attention  can  solve
 

conventions website, 2017
some  long-term  memory  problems.  2016,  arXiv  preprint  arXiv: 48. Olsson  M.  Constants.  In:  Olsson  M,  ed.  Java  17  Quick  Syntax
 

1512.08756 Reference. 3rd ed. Berkele: Apress Berkele, 2022, 85−87
27. McCulloch  W  S,  Pitts  W.  A  logical  calculus  of  the  ideas  immanent  in
 

49. Fowler M. Refactoring: Improving the Design of Existing Code. 2nd ed.
 

nervous activity. The Bulletin of Mathematical Biophysics, 1943, 5(4): Reading: Addison-Wesley Professional, 2018
115–133 50. Mi Q, Xiao Y, Cai Z, Jia X. The effectiveness of data augmentation in
 

28. Nuñez-Varela  A  S,  Pérez-Gonzalez  H  G,  Martínez-Perez  F  E,

 

code  readability  classification.  Information  and  Software  Technology,

Soubervielle-Montalvo  C.  Source  code  metrics:  a  systematic  mapping 2021, 129: 106378
study. Journal of Systems and Software, 2017, 128: 164–197 51. Alon  U,  Zilberstein  M,  Levy  O,  Yahav  E.  Code2vec:  learning
 

29. Przybyłek  A.  Where  the  truth  lies:  AOP  and  its  impact  on  software
 

distributed  representations  of  code.  Proceedings  of  the  ACM  on

modularity.  In:  Proceedings  of  the  14th  International  Conference  on Programming Languages, 2019, 3(POPL): 40
Fundamental Approaches to Software Engineering. 2011, 447−461 52. Lee T, Lee J B, In H P. A study of different coding styles affecting code
 

30. Goel  B  M,  Bhatia  P  K.  Analysis  of  reusability  of  object-oriented
 

readability.  International  Journal  of  Software  Engineering  and  its

systems  using  object-oriented  metrics.  ACM  SIGSOFT  Software Applications, 2013, 7(5): 413–422
Engineering Notes, 2013, 38(4): 1–5 53. Sun H, Wang R, Chen K, Utiyama M, Sumita E, Zhao T. Unsupervised
 

31. Bruntink  M,  Van  Deursen  A.  An  empirical  study  into  class  testability.
 

bilingual  word  embedding  agreement  for  unsupervised  neural  machine

Journal of Systems and Software, 2006, 79(9): 1219–1232 translation.  In:  Proceedings  of  the  57th  Annual  Meeting  of  the
32. Poort  E  R,  Martens  N,  Van  De  Weerd  I,  Van  Vliet  H.  How  architects
 

Association for Computational Linguistics. 2019, 1235−1245
see  non-functional  requirements:  beware  of  modifiability.  In: 54. Chidamber  S  R,  Kemerer  C  F.  A  metrics  suite  for  object  oriented
 

Proceedings  of  the  18th  International  Conference  on  Requirements design.  IEEE  Transactions  on  Software  Engineering,  1994,  20(6):
Engineering: Foundation for Software Quality. 2012, 37−51 476–493
33. Alzahrani M, Alqithami S, Melton A. Using client-based class cohesion
 

55. Aniche M. Java code metrics calculator (CK), 2015
 

metrics  to  predict  class  maintainability.  In:  Proceedings  of  the  43rd 56. Svyatkovskiy A, Deng S K, Fu S, Sundaresan N. IntelliCode compose:
 

IEEE  Annual  Computer  Software  and  Applications  Conference code  generation  using  transformer.  In:  Proceedings  of  the  28th  ACM
(COMPSAC). 2019, 72−80 Joint  Meeting  on  European  Software  Engineering  Conference  and
34. Kanellopoulos Y, Antonellis P, Antoniou D, Makris C, Theodoridis E,
 

Symposium  on  the  Foundations  of  Software  Engineering.  2020,

Tjortjis  C,  Tsirakis  N.  Code  quality  evaluation  methodology  using  the 1433−1443
ISO/IEC  9126  standard.  International  Journal  of  Software  Engineering 57. Svyatkovskiy A, Zhao Y, Fu S, Sundaresan N. Pythia: AI-assisted code
 

& Applications, 2010, 1(3): 17–36 completion  system.  In:  Proceedings  of  the  25th  ACM  SIGKDD
35. Malhotra R, Lata K. An empirical study to investigate the impact of data
 

International  Conference  on  Knowledge  Discovery  &  Data  Mining.

resampling  techniques  on  the  performance  of  class  maintainability 2019, 2727−2735
prediction models. Neurocomputing, 2021, 459: 432–453 58. Li  Y,  Yang  Z,  Guo  Y,  Chen  X.  Humanoid:  a  deep  learning-based
 

36. Padhy  N,  Panigrahi  R,  Neeraja  K.  Threshold  estimation  from  software
 

approach  to  automated  black-box  android  app  testing.  In:  Proceedings

metrics  by  using  evolutionary  techniques  and  its  proposed  algorithms, of  the  34th  IEEE/ACM  International  Conference  on  Automated
models. Evolutionary Intelligence, 2019, 14(2): 315–329 Software Engineering (ASE). 2019, 1070−1073
37. Shatnawi  R.  Comparison  of  threshold  identification  techniques  for
 

59. Gu X, Zhang H, Zhang D, Kim S. Deep API learning. In: Proceedings
 

object-oriented software metrics. IET Software, 2020, 14(6): 727–738 of  the  24th  ACM  SIGSOFT  International  Symposium  on  Foundations

38. Ferreira K A M, Bigonha M A S, Bigonha R S, Mendes L F O, Almeida
 

of Software Engineering. 2016, 631−642
H C. Identifying thresholds for object-oriented software metrics. Journal 60. Goodfellow I, Bengio Y, Courville A. Deep Learning. Cambridge: MIT
 

of Systems and Software, 2012, 85(2): 244–257 Press, 2016
39. Hofmeister  J,  Siegmund  J,  Holt  D  V.  Shorter  identifier  names  take
 

61. Lever  J,  Krzywinski  M,  Altman  N.  Logistic  regression.  Nature
 

longer  to  comprehend.  In:  Proceedings  of  the  24th  IEEE  International Methods, 2016, 13(7): 541–543
Conference  on  Software  Analysis,  Evolution  and  Reengineering 62. Zhang Y, Zhou M, Mockus A, Jin Z. Companies’ participation in OSS
 

(SANER). 2017, 217−227 development−an  empirical  study  of  OpenStack.  IEEE  Transactions  on

40. Morales  R,  Khomh  F,  Antoniol  G.  RePOR:  mimicking  humans  on
 

Software Engineering, 2021, 47(10): 2242–2259
refactoring  tasks.  Are  we  there  yet?  Empirical  Software  Engineering, 63. Amreen  S,  Mockus  A,  Zaretzki  R,  Bogart  C,  Zhang  Y  X.  ALFAA:
 

2020, 25(4): 2960–2996 active  learning  fingerprint  based  anti-aliasing  for  correcting  developer

41. Hussain Y, Huang Z, Zhou Y. Improving source code suggestion with
 

identity  errors  in  version  control  systems.  Empirical  Software

code  embedding  and  enhanced  convolutional  long  short-term  memory. Engineering, 2020, 25(2): 1136–1167
IET Software, 2021, 15(3): 199–213 64. El  Emam  K,  Benlarbi  S,  Goel  N,  Rai  S  N.  The  confounding  effect  of
 

42. Scalabrino S, Bavota G, Vendome C, Linares-Vasquez M, Poshyvanyk
 

class size on the validity of object-oriented metrics. IEEE Transactions
D,  Oliveto  R.  Automatically  assessing  code  understandability.  IEEE on Software Engineering, 2001, 27(7): 630–650
Transactions on Software Engineering, 2021, 47(3): 595–613 65. Bengio  Y.  Practical  recommendations  for  gradient-based  training  of
 

43. Smith  N,  Van  Bruggen  D,  Tomassetti  F.  JavaParser:  Visited.  Victoria:
 

deep architectures. In: Montavon G, Orr G B, Müller K R, eds. Neural
Leanpub, 2021 Networks: Tricks of the Trade. Berlin: Springer, 2012, 437−478
44. Jiang Y, Liu H, Zhu J, Zhang L. Automatic and accurate expansion of
 

66. Wang W, Li G, Shen S, Xia X, Jin Z. Modular tree network for source
 

abbreviations  in  parameters.  IEEE  Transactions  on  Software code  representation  learning.  ACM  Transactions  on  Software
Engineering, 2020, 46(7): 732–747 Engineering and Methodology, 2020, 29(4): 31
45. Butler S. The effect of identifier naming on source code readability and
 

67. Allamanis M, Barr E T, Bird C, Sutton C. Suggesting accurate method
 

quality. In: Proceedings of the Doctoral Symposium for ESEC/FSE on and  class  names.  In:  Proceedings  of  the  10th  Joint  Meeting  on
Doctoral Symposium. 2009, 33−34 Foundations of Software Engineering. 2015, 38−49
46. Lawrie  D,  Feild  H,  Binkley  D.  Quantifying  identifier  quality:  an
 

68. Baranasuriya  N.  Java  Coding  Standard.  See  se-education/guides/

 

analysis  of  trends.  Empirical  Software  Engineering,  2007,  12(4): conventions/java/index website, 2022

359–388 69. Triguero I, González S, Moyano J M, García S, Alcalá-Fdez J, Luengo
 
 Yamin HU et al.    Measuring code maintainability with deep neural networks
J,  Fernández  A,  Del  Jesús  M  J,  Sánchez  L,  Herrera  F.  KEEL  3.0:  an
open  source  software  for  multi-stage  analysis  in  data  mining.
International  Journal  of  Computational  Intelligence  Systems,  2017,
10(1): 1238–1249
70. Zerouali A, Mens T. Analyzing the evolution of testing library usage in
open  source  java  projects.  In:  Proceedings  of  the  24th  IEEE
International  Conference  on  Software  Analysis,  Evolution  and
Reengineering (SANER). 2017, 417−421
Yamin  Hu  received  a  BSc  degree  from  the
College  of  Information  Engineering,  Northwest
A&F University, China in 2016, and MSc degree
from  the  School  of  Computer  Science  and
Technology,  University  of  Science  and
Technology  of  China,  China  in  2019.  He  is
currently  working  toward  a  PhD  degree  at  the
School  of  Computer  Science  and  Technology,  Beijing  Institute  of
Technology,  China.  His  current  research  interests  include  software
engineering and database systems.
15
Hao  Jiang  received  a  BSc  degree  from  the
Department  of  Computer  Science  and
Technology,  North  China  Electric  Power
University,  China  in  2014,  and  PhD  degree  from
the School of Computer Science and Technology,
University  of  Science  and  Technology  of  China,
China. He is currently an Associate Professor with
the  School  of  Artificial  Intelligence,  Anhui  University,  China.  His
current  research  interests  include  complex  network  analysis,
combinatorial optimization, and computational intelligence.
Zongyao Hu is currently pursuing the PhD degree
with  the  School  of  Computer  Science  and
Technology,  Beijing  Institute  of  Technology,
China. His current research interests include deep
learning and image processing.