.pdfpng.pngconvert #1 .pdf language = Java, basicstyle = , stringstyle = ,
keywordstyle = , keywordstyle = [2], keywordstyle = [3], keywordstyle = [4],
morekeywords = [3]¡¡, ¿¿, morekeywords = [4]++, basicstyle=, commentstyle=,
morecomment=[f][]-, morecomment=[f][]+, morecomment=[f][]++,
morecomment=[f][]\--, morecomment=[f][]@@, texcl=false

# Moving beyond Deletions: Program Simplification via Diverse Program
Transformations

Haibo Wang  Concordia UniversityMontrealCanada<EMAIL_ADDRESS>,
Zezhong Xing  Southern University of Science and TechnologyShenzhenChina
<EMAIL_ADDRESS>,  Zheng Wang  University of LeedsLeedsUK
<EMAIL_ADDRESS>,  Chengnian Sun  University of WaterlooWaterlooCanada
<EMAIL_ADDRESS>and  Shin Hwei Tan  Concordia UniversityMontrealCanada
<EMAIL_ADDRESS>
(2018)

###### Abstract.

To reduce the complexity of software, Developers manually simplify program
(known as developer-induced program simplification in this paper) to reduce
its code size yet preserving its functionality but manual simplification is
time-consuming and error-prone. To reduce manual effort, rule-based approaches
(e.g., refactoring) and deletion-based approaches (e.g., delta debugging) can
be potentially applied to automate developer-induced program simplification.
However, as there is little study on how developers simplify programs in Open-
source Software (OSS) projects, it is unclear whether these approaches can be
effectively used for developer-induced program simplification. Hence, we
present the first study of developer-induced program simplification in OSS
projects, focusing on the types of program transformations used, the
motivations behind simplifications, and the set of program transformations
covered by existing refactoring types. Our study of 382 pull requests from 296
projects reveals that there exist gaps in applying existing approaches for
automating developer-induced program simplification. and outlines the criteria
for designing automatic program simplification techniques. Inspired by our
study and to reduce the manual effort in developer-induced program
simplification, we propose SimpT5, a tool that can automatically produce
simplified programs (semantically-equivalent programs with reduced source
lines of code). SimpT5 is trained based on our collected dataset of 92,485
simplified programs with two heuristics: (1) _simplified line localization_
that encodes lines changed in simplified programs, and (2) checkers that
measure the quality of generated programs. Our evaluation shows that SimpT5
are more effective than prior approaches in automating developer-induced
program simplification.

Program Simplification, Program Reduction, Refactoring

††conference: ACM Conference; X, 2024; X, X††copyright:
acmcopyright††journalyear: 2018††doi: XXXXXXX.XXXXXXX††price: 15.00††isbn:
978-1-4503-XXXX-X/18/06††ccs: Software and its engineering General programming
languages

##  1\. Introduction

Software systems have become increasingly more complex. To ease software
maintenance, developers often dedicate significant time to simplify programs
manually - a process referred to as _developer-induced program simplification_
in this paper. The goal is to reduce the code size or the number of lines of
code of the programs while preserving their functionalities. As defects can be
introduced when modifying programs by hand (Ge et al., 2012), manual program
simplification is error-prone. Meanwhile, several techniques can potentially
be applied for automating developer-induced program simplification: (1) rule-
based approaches such as refactoring that restructures code via a predefined
set of _syntactic program transformations_ (Becker et al., 1999) (also known
as _refactoring types_), and (2) deletion-based techniques such as delta
debugging (Zeller and Hildebrandt, 2002) that performs _semantic program
simplification_ by relying on test executions to check whether removing parts
of the input program leads to a smaller program that is semantically
equivalent to the original program.

Refactoring, a representative of rule-based approaches, has been extensively
studied. Most prior research efforts in this direction focus either on
investigating the refactoring practice (Oliveira et al., 2023; Ge et al.,
2012; Kim et al., 2012; Paixão et al., 2020; Peruma et al., 2022; AlOmar et
al., 2019) or designing automated refactoring techniques (Gyori et al., 2013;
Binkley et al., 2005; Meng et al., 2015; Jensen and Cheng, 2010; Karakati and
Thirumaaran, 2022). However, the findings of these studies and the
effectiveness of prior refactoring techniques may not be applicable in the
context of developer-induced program simplification because (1) they mainly
focus on a limited set of supported refactoring types (e.g., RefactoringMiner
can detect 99 refactoring types), and (2) some refactoring types may not have
the desired properties of a simplified program (having reduced code size while
preserving the program behavior). For example, “Extract Local Variable”, a
popular refactoring type, may introduce an additional line of code due to the
insertion of a new variable.

Meanwhile, deletion-based techniques have demonstrated promising results in
automatically producing reduced programs that can be used as inputs for
several domains, including debugging (Zeller, 1999; Hammoudi et al., 2015),
test case simplification (Zhang, 2013; Zeller and Hildebrandt, 2002; Jiang et
al., 2017), and improving the understanding of features in neural code
intelligence system (Rabin et al., 2022). Understanding the types of program
transformations used in developer-induced program simplification is essential
as it can potentially enhance these domains where deletion-based techniques
are used by producing more diverse reduced programs.

Table 1. Differences with relevant work that aim to produce reduced programs

Approach Simplification Goals Transformations Simplification Technique Tests
Delta DebuggingD Debugging, test input minimization, feature isolation
Deletion Delta debugging (Zeller, 1999; Zeller and Hildebrandt, 2002),
hierarchical delta debugging (Misherghi and Su, 2006; Hodován et al., 2017)
Need to run tests Program ReductionD Test case minimization Deleting/Replacing
bug-irrelevant elements Perses (Sun et al., 2018), Vulcan (Xu et al., 2023)
Need to run tests Program DebloatingD Reduce attack surfaces Deletion Combine
with delta debugging (Heo et al., 2018), Dependency Analysis (Qian et al.,
2019) Need to run tests Program SlicingD Debugging, testing, software
maintenance Deletion* Dependency Analysis (Agrawal and Horgan, 1990; Harman
and Danicic, 1995; Lu and Debray, 2012; Binkley et al., 2013; Wong et al.,
2023) May/May not run tests Simplication in GPR Enforce explanability of
models Rule-based Transformations Simplification Rules (e.g., algebraic,
numerical) May/May not run tests RefactoringR Software maintenance Rule-based
Transformations Rules based on refactoring types (Zhang, 2013; Nievergelt,
1965; Zeller and Hildebrandt, 2002; Jiang et al., 2017; Tsantalis et al.,
2020, 2018b) May/May not run tests Our Work Generate Diverse Transformations
Based on deep learning and LLMs Need to run tests

  * •

Approaches marked with D represents deletion-based approaches, whereas
approaches marked with R denotes rule-based approaches. *We consider program
slicing as a deletion-based approach that removes statements without
dependency from the original program.

To fill in the gaps of prior studies and techniques, we present the first
study of the characteristics of developer-induced program simplification in
open-source software (OSS) projects in GitHub. Specifically, our study
investigated _the types of program transformations used and the motivations
behind developer-induced program simplification_ by answering the research
questions below:

RQ1:

What are the program transformations commonly used in developer-induced
program simplification?

RQ2:

What are the motivations behind developer-induced program simplification in
OSS projects?

RQ3:

What are the program transformations covered by existing refactoring types?

RQ4:

How effective are prior tools for refactoring detection (RefactoringMiner) and
refactoring automation (JDeodorant) in detecting and automating developer-
induced program simplification?

As refactoring and developer-induced program simplification aim to improve
code while preserving program semantics, we investigated the feasibility of
reusing existing tools for detecting and automating refactoring for developer-
induced program simplification.

Based on the findings of our study, we propose SimpT5, a tool that automates
developer-induced program simplification by integrating (1) syntactic program
transformations by using a diverse set of program transformations and (2)
semantic program simplifications by using tests to check for test-equivalent
relations.

In summary, we made the following contributions:

  * •

To the best of our knowledge, we present the first study of the program
transformations used by developers and the motivations that drive developers
when performing developer-induced program simplification. The key findings of
our study include (1) there are diverse types (26 types) of program
transformations used in developer-induced program simplification, (2) several
frequently used simplification types have not been covered by deletion-based
approaches and prior refactoring types (e.g., replacing a code block with an
API call and simplifying expressions), (3) among the supported refactoring
types, prior refactoring detection engine is still limited due to complex rule
design, (4) prior auto-refactoring tools fail to automate many
simplifications, indicating the need for a new tool with a richer set of
transformations.

  * •

We introduce SimpT5, a proof-of-concept simplification framework based on
pretrained large language model that uses two heuristics: (1) simplified line
localization (encode line to be simplified), (2) checkers that evaluate the
quality of generated programs via static metrics observed in our study.

  * •

We propose SimpliBench, a benchmark containing 37846 code simplification
commits from 25022 open-source Java projects. We also derive a _valid_ dataset
from this benchmark, which contains 329 simplification commits across 307
projects. The _valid_ dataset contains commits that are compilable together
with tests to validate the quality of the generated programs. Our evaluation
on SimpliBench shows that SimpT5 can automatically simplify code with 30%
exactly match rate. The dataset and the source code are publicly available at
(dat, [n. d.]).

##  2\. Related Work and Problem Formulation

Table 1 highlights the differences between our work and prior techniques that
produce programs of reduced sets. The problem of _automated program
simplification_ was widely studied (Zhang, 2013; Zeller and Hildebrandt, 2002;
Jiang et al., 2017) with the earliest work dated back to 1965 (Nievergelt,
1965). We briefly discuss prior definitions of program simplification below:

Syntactic program simplification. According to (Nievergelt, 1965), syntactic
program simplification refers to _“simplifications which depend on the form of
the program only, i.e. can be detected and proved to lead to an equivalent
program without knowledge of what the program is supposed to do”_. This
approach focuses on using a set of transformations known to preserve program
equivalence. It is aligned with rule-based techniques (such as refactoring) in
Table 1, where equivalent-preserving transformations are applied to enhance
program design (Becker et al., 1999). Therefore, we define _syntactic program
simplification_ as a method for obtaining simpler programs (with fewer lines
of code) through semantic-preserving transformations. Typically, these
techniques employ static analysis to verify equivalence.

Refactoring, a representative for syntactic program simplification has been
widely studied where most studies focus on the refactoring practice (Kim et
al., 2012; Paixão et al., 2020; Peruma et al., 2022; AlOmar et al., 2019). To
reduce the time and effort in manual refactoring, many automated refactoring
approaches have been proposed (Gyori et al., 2013; Binkley et al., 2005; Meng
et al., 2015; Jensen and Cheng, 2010; Karakati and Thirumaaran, 2022). Several
approaches use refactoring to support code review (Alizadeh et al., 2019;
Brito and Valente, 2021; Tsantalis et al., 2020). Some of the program
transformations found in our study are commonly used in refactoring tools
(e.g., lambda expressions (Gyori et al., 2013; Tsantalis et al., 2017)). The
key difference between refactoring and developer-induced program
simplification is that it has the additional criterion that the resulting
transformed program should be smaller (reduced lines of code), whereas
refactoring does not necessarily lead to reduced code size.

Semantic program simplification. Several automatic program simplification
techniques _rely on test executions (e.g., test outcome) to check for
behavioral equivalence when automatically generating smaller programs_ (we
call these techniques _semantic program simplification_) (Lu and Debray, 2012;
Harman and Danicic, 1995; Agrawal and Horgan, 1990; Zeller, 1999; Hammoudi et
al., 2015; Zhang, 2013; Jiang et al., 2017). Semantic program simplification
have been applied in many domains (e.g., simplifying event sequences in apps
(Jiang et al., 2017), deobfuscation (Lu and Debray, 2012)).

In terms of transformations used, these techniques either rely on deletions
(delta debugging) or obtain a reduced list of program statements by focusing
on a slicing criterion (dynamic slicing). We refer to these techniques as
deletion-based approaches in Table 1. Several techniques use limited types of
transformation (e.g., mutation and crossover operators for pixel shader
simplification (Sitthi-Amorn et al., 2011), _remove_ and _move_ for debugging
concurrent programs (Jalbert and Sen, 2010), replacing identifier and subtrees
of parse tree for program reduction (Xu et al., 2023)). These techniques
usually rely on a variant of: (1) delta debugging (Zeller, 1999; Zeller and
Hildebrandt, 2002), and (2) dynamic slicing (Agrawal and Horgan, 1990; Harman
and Danicic, 1995; Lu and Debray, 2012; Fan et al., 2023; Binkley et al.,
2014). Delta debugging increasingly deletes smaller parts of the input file
and run tests to check if the simplified input changes the test outcome
(Zeller and Hildebrandt, 2002; Zeller, 1999). Dynamic slicing focuses on “all
statements that actually affect the value of a variable occurrence for a given
program input” (Agrawal and Horgan, 1990). Our work is different from dynamic
slicing or its variants (e.g., observation-based slicing (Binkley et al.,
2013)) in that: (1) slicing-based techniques aim to isolate feature-related
elements (e.g., statements) under certain criteria, whereas we focus on the
program itself, we aim to obtain a smaller program (reduced lines of code)
which satisfies the criteria; (2) we obtain various transformation types which
preserve the original program’s behaviour for program simplification. Our set
of transformations serves as the basis for providing more candidates for
slicing-based techniques, which facilitate debugging.

Large language models for program transformation. Large language models (LLMs)
have shown promising results in code-related tasks. Most prior learning-based
approaches either focus on tasks like method name recommendations (Jiang et
al., 2019; Parsa et al., 2023; Liu et al., 2022), code smell detection (Sharma
et al., 2021; Liu et al., 2019a; Fontana et al., 2013; Azeem et al., 2019;
Pecorelli et al., 2020) or bug fixing (Zhang et al., 2022; Fan et al., 2023).
The most relevant techniques to us are the two general-purpose code
transformation models: TufanoNMT (Tufano et al., 2019a) and AutoTransform
(Thongtanunam et al., 2022). Differs from prior approaches, our approach
focuses on generating simplified programs with diverse test-equivalent program
transformations.

Developer-induced program simplification. As noted in prior work (Nievergelt,
1965), when simplifying a program by hand, developers usually have the
required domain knowledge to produce semantically equivalent programs that are
smaller. Hence, _we study the problem of developer-induced program
simplification_ that combines the best of both worlds by including (1)
syntactic program transformation, and (2) semantic program simplification.

###### Definition 0 (Test equivalent).

Given a pair of programs $(P,P^{\prime})$ and a test suite $T$ executable in
$P$ and $P^{\prime}$, $P$ and $P^{\prime}$ are test-equivalent if $\forall
t_{k}\in T$ where each test $t_{k}$ takes as input $inp_{k}$ and produces
output $out_{k}$, $P$($inp_{k}$)=$P^{\prime}$($inp_{k}$)=$out_{k}$ (i.e., for
all tests in $T$, $P$ and $P^{\prime}$ produce the same outputs).

###### Definition 0 (Program Simplification).

Given a program $P$, and a transformed program $P^{\prime}$, $P^{\prime}$ is a
simplified program of $P$ if (1) $P^{\prime}$ contains less Source Lines of
Code (SLOC) than $P$, and (2) $P$ and $P^{\prime}$ are test-equivalent.

Although there are various granularity levels (e.g., statement, line or
character) used in prior techniques, we choose SLOC to represent simplified
programs because it has been widely used in deletion-based (Zeller, 1999;
Zeller and Hildebrandt, 2002; Hodován and Kiss, 2016) and rule-based
approaches (Dig et al., 2009). When the SLOCs remain the same, we consider the
reduction in the number of tokens.

##  3\. Understanding Developer-induced Program Simplification

Table 2. Taxonomy of program simplification in studied OSS projects

Category Sub-category Description Refactoring PRs (#/%) Total (#/%) (T1)
Control logic (T1.1) Simplify method return Simplify program logic related to
method return value Y 53/13.87 151/39.53 (T1.2) Simplify boolean and algebraic
expression Simplify boolean and algebraic expression by rules N 32/8.42 (T1.3)
Use foreach in loop iterationL Foreach loops can avoid potential off-by-one
errors and reduce lines Y 15/3.93 (T1.4) Merge conditional Merge if statements
that resulting action is the same Y 13/3.40 (T1.5) Ternary conditional
operatorL Simplify conditional statements via ternary conditional operator Y
11/2.88 (T1.6) Restructure conditional branches Replace complex conditional
branches by using enum, polymorphism, and etc. Y 9/2.36 (T1.7) Replace with
pipeline Chain operations together by stream pipelining Y 6/1.57 (T1.8)
Replace variable with attribute Replace variables in method with attributes Y
6/1.57 (T1.9) Merge catch Merge multiple catch together if they contain
duplicated code Y 5/1.31 (T1.10) Change return type Change method return to
void and delete statements Y 1/0.26 (T2) Extraction (T2.1) Extract method
Extract code blocks as methods to improve reusability Y 75/19.63 120/31.41
(T2.2) Extract variable Extract common variables Y 40/10.47 (T2.3) Consolidate
duplicate conditional fragments Pull up common head or pull down common tail
of conditional to reduce duplication Y 5/1.31 (T3) Deletion (T3.1) Remove
unnecessary code Remove duplicated or unneeded code N 47/12.30 63/16.49 (T3.2)
Remove unused imports Remove unused imports NT 11/2.88 (T3.3) Clean up dead
code blocks Remove dead code blocks that can not be visited Y 5/1.31 (T4) API
(T4.1) Replace with equivalent API Replace code block with semantically-
equivalent APIs N 62/16.23 62/16.23 (T5) Inline code (T5.1) Inline variable
Inline temporary variables that are only used once Y 38/9.95 47/12.30 (T5.2)
Inline method Inline simple small method that are only used once Y 9/2.36 (T6)
Lambda (T6.1) Use lambdaL Simplify using lambda expression Y 44/11.52 44/11.52
(T7) Others (T7.1) Use diamond operatorL Simplify instantiation of generic
class (since Java 1.7) NT 16/4.19 46/12.04 (T7.2) Code style reformat Use
concise code style NT 9/2.36 (T7.3) Use constructor to initialize Use class
constructor to initialize the class properties Y 7/1.83 (T7.4) Merge imports
Merge multiple imports from the same package NT 6/1.57 (T7.5) Replace with
annotationsL Replace code fragments with annotations which achieve the same
functionality Y 6/1.57 (T7.6) Try-with-resourcesL Use try-with-resources
statement instead of finally block to close resources (since Java 1.7) NT
2/0.52

  * •

L The superscript ‘L’ indicates the program transformation uses language-
specific feature (e.g., foreach, lambda, diamond operator)

  * •

T The superscript ‘T’ indicates that although it is not a refactoring type,
there is IDE plugin that supports the transformation.

We study developer-induced program simplification by manually inspecting
commits within pull requests (PRs) in Java open-source GitHub projects. We
choose Java because it is one of the most popular programming languages. We
concentrate on PRs as they contain detailed discussions to help us classify
the simplification types and understand the motivations behind them.

###  3.1. Research Methodology

####  3.1.1. Mine developer-induced program simplification in PRs

We developed a crawler using the GitHub API to search for PRs related to code
simplification using keyword “simplify code”
111https://developer.github.com/v3/. We tried other keywords like “shorten”,
“reduce”, and “shrink” and found out that the resulting PRs contained too many
non-simplified PRs. After retrieving the top 1000 relevant PRs, we manually
reviewed each one to exclude those that did not clearly focus on
simplification, were irrelevant to code simplification, or did not reduce
lines of code. This process resulted in 382 PRs from 296 repositories.

####  3.1.2. Derive taxonomy of transformation types

After receiving simplification commits in PRs, we developed a taxonomy through
manual analysis of code changes in each PR using thematic analysis (Cruzes and
Dyba, 2011) – an approach that identifies patterns (or “themes”) within data.
To this end, we recruited two human raters to develop the taxonomy. Both
raters were graduate students with over two years of Java programming
experience. They followed the following steps independently, with conflicts
resolved in meetings. First, we carefully reviewed PR titles, descriptions,
and discussions to understand developers’ motivations and the simplification
process. We identified simplification commits by examining commit messages. If
no explicit simplification-related keywords were found, we checked all PR
commits. Next, we coded key “diff hunks” (i.e., code changes performing
simplification) in each commit, describing transformation types. We
iteratively refined codes by reviewing related diff hunks and their context.
We grouped key diff hunks based on codes, providing an overview of main edit
actions and recurring patterns. Codes with similar meanings were aggregated
into groups to derive broader themes. Finally, we reviewed and merged similar
themes to define the final set, reducing research bias. During the rating, our
rators achieved an initial Cohen’s Kappa of 0.81. Disagreements were resolved,
resulting in a Cohen’s Kappa of 1.0.

###  3.2. RQ1: Set of Transformations

Before following the steps of thematic analysis, we reviewed syntactic and
semantic program simplification principles together with program refactoring
from prior studies (Nievergelt, 1965; Zeller and Hildebrandt, 2002). Table 2
lists the identified types of program transformations across 382 PRs across
296 projects used in developer-induced program simplification. Note that a PR
may contain multiple diff hunks where each diff hunk group may correspond to a
particular transformation type, leading to multiple transformation types. The
“Category” column in Table 2 describes the high-level types of the program
simplification, while the “Sub-category” column gives the specific categories.
The last column (Category Total (#/%)) presents the total number and
percentage of PRs that fit into a particular category. In total, we identified
seven main categories with 26 sub-categories. Among the seven categories, we
observed that mere deletion only exists in 16.49% of the investigated PRs.
This indicates that there _exists a missing gap in prior deletion-based
approaches_ (marked as “D” in Table 1), i.e., they can only fulfil the needs
of up to 16.49% developer-induced program simplification.

“Extract method” is the most commonly used transformation. This result is
inline with prior studies that revealed that “extract method” is the most
popular and most well-motivated refactoring among developers (Silva et al.,
2016). As our study shows that “extract method” is frequently used in
developer-induced program simplification, it provides empirical evidence that
developers still often perform “extract method” refactoring manually. However,
prior study shows that manual refactoring often leads to mistakes (Murphy-Hill
and Black, 2008).

Table 2 also shows that there are _simplification types that are Java
language-specific_ (foreach, ternary conditional operator, lambda, diamond
operator, and annotations). This indicates that developers prefer using
language features to simplify programs. Meanwhile, designers of future
automated program simplification tools should incorporate these language
features.

Finding 1: Developer-induced program simplification includes 26 transformation
types where deletion only exists in 16.49% of studied PRs. “Extract method”
(19.63%) and “Replace with equivalent API” (16.23%) are the two most
frequently used transformations. Some transformations involve language-
specific features. Implication 1: The types of transformations used in
developer-induced program simplification are diverse. To enhance reusability,
developers often introduce new method or replace with an API call. When
simplifying programs, developers also often use language-specific features
(e.g., foreach, lambda). Several widely used transformations (e.g., “Replace
with equivalent API”) have not been automated by any existing tool, indicating
a need to design new tools to support these transformations.

###  3.3. RQ2: Motivations Behind Simplifications

We carefully read each PR’s title, description and discussions to analyze the
motivations for simplification. In some PRs, developers only state “what”
(changes they have done) without “why” (the motivations), so for RQ2, we only
keep PRs with clear descriptions of the motivations. We use the same
procedures described in Section 3.1. This results in 79 out of total 382
studied PRs.

Table 3. Motivations for simplifying programs Category | Description | GitHub PRs (#/%)
---|---|---
Cleanup code (Zeller, 1999; Zeller and Hildebrandt, 2002; Hodován and Kiss, 2016) | Remove unnecessary code | 49/62.03
Readability (Buse and Weimer, 2008; Posnett et al., 2011; Muñoz Barón et al., 2020) | Improve readability | 21/26.58
Complexity (McCabe, 1976; Campbell, 2018; Ebert et al., 2016) | Reduce complexity | 7/8.86
Reusability (Bansiya and Davis, 2002; Washizaki et al., 2004; Rathee and Chhabra, 2022) | Reuse existing code | 3/3.80

Table 3 shows the four main motivations, including “Readability” (26.58%),
“Complexity” (8.86%), “Cleaning up code” (62.03%), and “Reusability” (3.80%).
Note that one PR might contain multiple motivations for program
simplification. Compared to prior refactoring studies (Silva et al., 2016;
AlOmar et al., 2021; Kim et al., 2012), the main motivations of developer-
induced program simplification are generally similar, with the focus being on
removing duplication. Notably, we also observe from Table 3 that _all
motivations of developer-induced program simplification can be automatically
measured using prior metrics_ , indicating the promise of using existing
metrics to assess the quality of simplified programs.

Finding 2: The motivations that drive developer-induced program simplification
is generally similar to those of refactoring. These include: (1) cleaning up
code, (2) improving readability, (3) reducing complexity, and (4) improving
reusability. All motivations can be automatically measured using prior code
metrics. Implication 2: As all motivations can be automatically measured using
prior metrics, this shows the promise of using these metrics to assess the
quality of simplified programs.

###  3.4. Supported Refactoring Types

We conducted two studies to analyze the overlap in program transformations
between developer-induced program simplification and those supported by
refactoring tools. First, we used RefactoringMiner (Tsantalis et al., 2020,
2018b) to identify if our transformations correspond to known refactorings,
supplemented by prior studies and Martin Fowler’s refactoring catalog (Becker
et al., 1999) for identifying refactoring-based program simplifications.
Second, to understand the detection challenges, we ran RefactoringMiner on
simplification commits and contacted its developers to confirm if each
transformation fits into currently supported refactoring types, understand
detection challenges, and report detection failures.

####  3.4.1. Covered by refactoring

Table 2 shows the overlapping (“Y”) and non-overlapping transformations (“N”)
with refactoring types and those supported as IDE plugins (“T”). Notably,
control-logic modifications (39.53%) are frequently seen in developer-induced
program simplification, but refactoring tools only support a subset.
Additionally, 31.41% of the developer-induced program simplification involves
extraction, a prevalent refactoring technique replacing code blocks with
equivalent methods, variables, or statements.

####  3.4.2. Beyond refactoring

Some simplifications do not align with well-established refactoring types. The
second-frequently used type (16.23%) replaces method code snippets with
semantically equivalent APIs, like Arrays.fill() or StringUtils.isEmpty().
Listing 1 gives an example for using Arrays.fill() to replace the code block
that implements the same function. While existing studies on API
recommendation (Huang et al., 2018; Rahman et al., 2016; He et al., 2021)
focus on suggesting APIs based on language descriptions, we found no technique
that automatically substitutes code blocks with equivalent API calls to
improve robustness readability and reduce code size.

⬇

1- Entry[] tab = table;

2- for (int i = 0; i < tab.length; i++)

3- tab[i] = null;

4+ Arrays.fill(table, null);

Listing 1: Example of “Replace with equivalent API”

Based on the discussion with RefactoringMiner’s developers, “Replace with
equivalent API” can be theoretically supported via combined operations that
perform multi-project code clone detection, aggregate similar code snippets,
extract methods and then invoke these methods. Moreover, when selecting the
appropriate APIs to replace, automated tools need to consider (1) the security
of the used APIs (Madden, 2020) and security of the dependencies of the used
APIs and (2) API misuse (Zhang et al., 2018; Nguyen et al., 2019) as
inexperienced programmers may use API incorrectly.

_Simplify boolean expression (#32, 8.42%)._ Simplifying boolean expressions
can lead to cleaner code. Listing 2 shows an example where the expression
false == co.isExpired() is simplified via the semantically-equivalent
expression !co.isExpired(). Moreover, simplification can preserve errors and
non-termination (i.e., if false == co.isExpired() throws an exception or gets
stuck in an infinite loop, the simplified expression still has the same
behavior). In principle, we can simplify algebraic expressions by using rules
like cancellation, commutativity, associativity, and design rules that
enumerate all such semantically-equivalent expressions. However, it is time-
consuming to craft these rules and infeasible to include all equivalent
expressions.

⬇

1- if (false == co.isExpired()) {

2+ if (!co.isExpired()) {

3 return true;}

Listing 2: Example of “Simplify boolean expression”

_Diamond operator (#16, 4.19%)._ The diamond operator has been introduced
since Java 1.7 to simplify genetic instantiation. Listing 3 shows an example
of using the diamond operator for simplification.

⬇

1- Set<String> conditionKeys = new HashSet<String>();

2+ Set<String> conditionKeys = new HashSet<>();

Listing 3: Example of “using diamond operator”

_Try-with-resources (#2, 0.52%)._ The try-with-resources statement is a try
statement that declares one or more resources in it. A resource is an object
that must be closed once your program is done using it. For example, a File
resource or a Socket connection resource. The try-with-resources statement
ensures that each resource is closed at the end of the statement execution. So
the programmer don’t have to manually close those resources in the finally
block. Listing 4 shows an example of using the diamond operator for
simplification.

⬇

1- pluginManager.lock();

2- try {

3+ try (ResourceLock ignore = pluginManager.obtain()){

4 ...

5- finally { pluginManager.unlock(); }

Listing 4: Example of “Try-with-resources”

Finding 3: While most simplifications (70%) are covered by existing
refactoring types, 30% require new transformations: “Replace with equivalent
API” (17%), “Remove unnecessary code ” (13%), “Simplify boolean expression”
(9%), “Use diamond operator” (4%), “Remove unused imports” (3%), and “Try-
with-resources” (0.5%). Furthermore, five transformations are supported as IDE
plugins. Implication 3: Some newly discovered transformations are available as
standalone IDE plugins but cannot be found under the refactoring menu. As IDE
users have expressed difficulty in finding these transformations (org, [n.
d.]; dia, [n. d.]), it is worthwhile to group together program simplifications
to enhance usability. Meanwhile, most newly discovered developer-induced
program simplification cannot be easily supported by existing refactoring
engines due to (1) missing API information (“Replace with equivalent API”),
(2) a lack of exhaustive semantic-equivalent rules (‘Simplify boolean
expression” and “Simplify non-control statement”), and (3) uncertainty about
redundant code (“Remove unnecessary code ”). This indicates the need to design
new program simplification tools to automate these transformations.

For each commit, we also run RefactoringMiner to check if it can detect the
transformation. Notably, we found several scenarios where RefactoringMiner
fails to detect the transformations despite being in the list of supported
refactoring types. Listing 5 (inl, [n. d.]) shows an example where the “Inline
Variable” refactoring interleaved with method return operation, which we
classified as “ Simplify method return” (13.87%). Although RefactoringMiner
supports this transformation type, its newest version (V2.0.4 chrome
extension) failed to detect the example. After analyzing the implementation of
RefactoringMiner, we notice that the commit where the “Inline Variable”
refactoring is interleaved with the return statement causes the human-crafted
rules of RefactoringMiner to fail.

⬇

1 public String create() {

2- String token = UUID.randomUUID().toString();

3- return token;

4+ return UUID.randomUUID().toString();

5 }

6 private String createToken() {

7 CsrfToken csrfToken = new CsrfToken();

8- String token = csrfToken.create();

9- return token;

10+ return csrfToken.create();

11 }

Listing 5: RefactoringMiner fails to detect “Simplify method return” due to
interleaved transformations

We also found cases where RefactoringMiner cannot detect the complete mapping
for a multi-line transformation. For example, although RefactoringMiner can
detect the addition, removal, and modification of the annotations by matching
annotation type between two commits (Kim et al., 2021), it fails to provide
mapping to the users if they want to know which part of the code is replaced
by the added annotations. Listing 6 shows an example for the methods
getDefaultName() and setDefaultName(String defaultName) that are replaced with
the annotations @Getter and @Setter. RefactoringMiner can only detect that the
two annotations are added but fails to report the relationship between the
added annotations with the getter and setter. RefactoringMiner also offers
limited support for transformations with language-specific features. Except
for replacing anonymous with lambda, other simplifications using language-
specific features (e.g., foreach, diamond operator, try-with-resources) cannot
be detected by RefactoringMiner (13.09% of studied PRs).

⬇

1+ @Getter

2+ @Setter

3public class TestAppConfiguration {

4private String defaultName;

5- public String getDefaultName() {

6- return defaultName;

7- }

8- public void setDefaultName(String defaultName) {

9- this.defaultName = defaultName;

10- }

11}

Listing 6: Example of “Replace with annotations”

Finding 4: Among the supported refactoring types, RefactoringMiner is still
limited in: (1) handling refactorings that are not pure (interleaved with
other transformations), (2) providing a complete mapping for a multiline
transformation, and (3) handling language-specific features. These limitations
requires designing the rules for detection in RefactoringMiner. Implication 4:
Our study reveals several limitations of RefactoringMiner, including (1) the
detection rules for current refactoring should consider the complex situation
with interleaved transformations, (2) the detection for annotation should be
more fine-grained, the refactoring engine should offer maps between the
replaced code snippet with changed annotations, not only show which
annotations are added, deleted, or modified, (3) more support should be
offered to the transformations related with language-specific feature,
considering 13.09% of our studied PRs are related with it, and its prevalence
in the OSS repositories.

####  3.4.3. Automation

We analyze the possibility of automating program simplification by analyzing
the supported simplifications by two auto-refactoring tools (Tsantalis et al.,
2018a; Ouni et al., 2016).JDeodorant (Tsantalis et al., 2018a) is a code smell
detection tool that automatically identifies and applies refactoring.
JDeodorant supports five code smells (Feature Envy, Type/State Checking, Long
Method, God Class and Duplicated Code) where “Long Method” can be resolved by
“Extract Method” refactoring, and “Duplicated Code” problems can be resolved
by “Extract Clone” refactoring. As our study shows that only 31.41%
simplifications are related to the extraction, only up to 31.41%
simplifications can be recommended by JDeodorant in the best case. Meanwhile,
prior multi-objective approach supports 11 refactoring types (Ouni et al.,
2016) where three are simplification types.

After carefully analyzing studied simplifications, we identify the following
features: (1) the program token length before and after simplification are
relatively short (within 512 tokens). For example, the program before
simplifying using “Replace with equivalent API” is usually a contiguous code
snippet within a method scope, whereas the simplified program only contains a
few lines of API invocations; (2) the simplification types have some recurrent
patterns; (3) massive simplification data can be mined from GitHub. Based on
these features, we believe that deep-learning-based technology can be used to
automate program simplification.

Finding 5: Auto-refactoring tools (like JDeodorant) can be used to automate
developer-induced program simplification but they only support up to seven of
26 simplification types. Implication 5: Prior auto-refactoring tools fail to
cover most simplification types. Using deep-learning-based techniques trained
on a richer set of transformations could be promising.

##  4\. Methodology

Figure 1. Overall workflow of SimpT5.

Based on our study, we design SimpT5, a deep learning-based program
simplification framework. Figure 1 depicts the overall workflow of SimpT5
including three stages: (1) training, (2) inference, and (3) validation.

Training and test data collection. Although there are several refactoring
datasets available (Kádár et al., 2016; Hegedűs et al., 2018), some
simplification types are not covered by existing refactoring. Hence, we
propose SimpliBench, a new program simplification dataset that contains pairs
of ($P$, $P^{\prime}$) with the original method $P$ and its simplified version
$P^{\prime}$.

Table 4. Statistics of SimpliBench Statistic | Whole | Valid
---|---|---
# of Projects | 25,022 | 307
# of Method-pairs | 92,485 | 404
Mean # of tests in projects | - | 96
Mean SLOCs # of original method | 17 | 16
Mean SLOCs # of simplified method | 14 | 12

Select Developer-induced Program Simplification Commits. We use GHTorrent
(Gousios and Spinellis, 2012) to collect the related commits between 2011 and
2021. To remove commits irrelevant to program simplification, we only keep
commits with the keywords “simplify” or its derived words “simplification”,
“simplified”, together with “code” or “program” in their commit messages. As
we only focus on simplification for Java programs, we also filter commits
where the committed code changes contain no Java files. This results in 37846
commits from 25022 projects. To understand the noise this filtering mechanism
can potentially introduce, we manually examined a randomly selected sample of
100 commits filtered using this approach and found 89 simplification-related
commits. The manual analysis shows that the amount of noise (11%) is
reasonable for ML training on large training data (Kim et al., 2011). Next, we
split a commit according to _diff hunks_. As stated in Definition 2.2, program
simplification aims to reduce SLOCs while preserving the test-equivalent
behavior of the generated program. Hence, our crawler automatically selects
diff hunks which contain more deleted lines than added lines (code comments
and blank lines in the diff hunk are excluded while counting the lines of
code). We extract the method surrounding the diff hunk because (1) it contains
a logical set of relevant variables and could give semantic information about
the functionality (Tufano et al., 2019b; Lutellier et al., 2020; Jiang et al.,
2021); (2) compared to class, the method is relatively short with fewer
tokens, which is more friendly for deep learning model training or tuning as
maximum input and output sequence length is usually limited (e.g., the maximum
input sequence lengths for CodeT5 is 512 (Wang et al., 2021b)). In total, our
collected dataset contains 92,485 (original method, simplified method) pairs
from 25022 projects.

Data Preprocessing. After collecting the code samples, we then pre-process the
raw source into pairs at the method level, where each training sample contains
the original code and the simplified version (Fan et al., 2023; Le Goues et
al., 2012; Lutellier et al., 2020; Zhu et al., 2021; Liu et al., 2019b). As
shown in Figure 1, our code representation is based on the token sequence as
prior large language models trained on code (LLMC). Like (Tufano et al.,
2019b; Lutellier et al., 2020; Jiang et al., 2021), SimpT5 takes the tokenized
original method as input and produces the simplified method as output. We use
the byte-pair encoding (BPE) scheme (Sennrich et al., 2015) to build our
tokenizer. To avoid data leakage, we also test the trained model on code
samples extracted from _new, unseen_ projects. In our evaluation, we split the
data into training, validation, and testing sets with a ratio of 8:1:1 at the
project level (80% of projects into training, 10% into validation, and 10%
into testing).

Table 4 shows the statistics of SimpliBench. As some unmodified versions of
projects in our dataset may have syntax errors or test failures, we divide the
dataset into (1) _whole_ (include all collected simplified method pairs) and
(2) _valid_ (a subset of the whole dataset where the unmodified projects can
be compiled successfully and all tests within the test suite of the project
pass). To prepare the _valid_ dataset, we filter commits that (1) fail to
compile using mvn build command, and (2) do not have any test. Table 4 shows
that projects in SimpliBench contain a relatively large number of tests (on
average 96 tests), which allows us to check for test-equivalent.

###  4.1. Model Training and Tuning

Simplified line localization. Inspired by APR approaches (Fan et al., 2023; Le
Goues et al., 2012; Lutellier et al., 2020; Zhu et al., 2021; Liu et al.,
2019b) where fault localization is performed to identify the “buggy” lines in
which the transformations are applied, we propose _simplified line
localization_ to pinpoint the lines in the original program $P$ to apply the
program transformations from developer-induced program simplification to
produce the simplified program $P^{\prime}$. To encode simplified lines into
our code representation, we marked the original and the simplified code lines
with special tokens (¡original¿, ¡/original¿, ¡simplified¿, ¡/simplified¿). If
multiple _diff_ hunks exist, we will add these tokens to each changed line at
the beginning and end. We evaluate the effect of _perfect simplified line
localization_ (i.e., the lines modified by the correct developer-induced
program simplification) for program simplification, following prior APR
evaluation (Lutellier et al., 2020; Zhu et al., 2021). To evaluate the impact
of localization information on program simplification, we also design another
code representation without simplified line localization (i.e., with no
special tokens inserted) as a baseline comparison. In Section 5.3, our
experiment shows that adding simplified line localization helps improve the
model’s effectiveness.

Model design. Given the nature of our task, we use an Encoder-Decoder-based
LLMC (Wang et al., 2021b; Fu et al., 2022) as it is shown to be effective on
code transformation tasks. Our LLMC is trained through training samples and
hard prompts (Gu et al., 2021; Wang et al., 2022). By adding fixed natural
language instructions to the model input, hard prompt uses task-specific
knowledge learned during pre-training for the subsequent tuning stage.
Specifically, we use the prompt “ _Simplify the following java method: [X],
the simplified version is: [Y]_ ” where [X] represents the original method and
[Y] represents the simplified method. This natural language instruction is
designed for CodeT5.

Simplified program generation. In the generation phase, we use a common search
strategy called beam search to generate and rank a large number of candidate
predictions. For each iteration, the beam search algorithm checks the $n$ most
likely tokens (n corresponds to the beam width) and ranks them by the total
likelihood score of the next $s$ prediction steps (s corresponds to the search
depth). Subsequently, the beam search algorithm outputs the top $t$ most
likely sequences ordered based on the likelihood of each sequence.

Filtering unaltered programs. Among the generated simplified programs, we
notice that about 30% of them are the same with the original method (we call
these programs _unaltered programs_). As unaltered programs are naturally
semantically equivalent to the original programs and may mislead the
validation stage, we filter out all unaltered programs before the validation.

###  4.2. Validation Stage

Validation is the key step in ensuring the quality of the generated simplified
programs. As stated in Definition 2.2, given an original program $P$, we
consider a program as a simplified program $P^{\prime}$ if (1) $P^{\prime}$
contains less SLOCs than $P$, and (2) $P^{\prime}$ is test-equivalent with
$P$. To check for the (1) condition, we compare the SLOCs of $P$ and
$P^{\prime}$ to ensure that the code size of $P^{\prime}$ is reduced. To check
for the (2) condition, we first filter out simplified programs that do not
compile and then run each simplified program against the entire test suite to
check for test equivalent. Based on Finding 2, we designed a checker to
measure the differences between the original and simplified programs in
complexity and readability.

Cyclomatic complexity. One of the main motivations for developer-induced
program simplification is to reduce the complexity of a program. We use
cyclomatic complexity (McCabe, 1976; Campbell, 2018; Ebert et al., 2016), a
widely used metric to measure the complexity of a program.

Readability. We use cognitive complexity (Muñoz Barón et al., 2020) to measure
the readability of the simplified program. Cognitive complexity measures how
difficult it is for humans to read and understand a method.

##  5\. Evaluation

We evaluate the effectiveness of SimpT5 in automated program simplification
and answer the following research questions:

RQ5:

How effective is SimpT5 compared to other techniques?

RQ6:

How effective is simplified line localization in SimpT5?

RQ7:

Among the correctly generated programs, what are the transformation types used
to generate the simplified programs?

RQ8:

What is quality of the generated programs by SimpT5 compared to other tools?

###  5.1. Experimental Setup

####  5.1.1. Implementation

We use the pre-trained CodeT5-base model and corresponding tokenizer in the
official repository Huggingface (Hug, [n. d.]). Our implementation of prompt-
tuning is based on OpenPrompt (Ope, [n. d.]). We use the generic training
strategy and parameter settings following the official implementation of
CodeT5 (Wang et al., 2021b). Specifically, we set the learning rate to be
$5e^{-5}$ and use AdamW optimizer with a linear warmup to optimize the model.
The training and validation batch size is 8. We tun the CodeT5-base model for
50 epochs. The maximum length of input and output text is set to 512. During
training, we set beam size to 1 and 10. All experiments are conducted on
Ubuntu 20.04 with 2x 24GB GeForce RTX 3090 GPUs. For the generated simplified
programs, we first replace the original method with the simplified one, then
compile the entire project under JDK1.8.0 and JDK11.0.15 during the validation
step. When validating candidate programs, we sample from the model up to beam
size = 1 and 10 predictions to be validated. SimpT5 validates simplifications
candidates automatically where only the first one (if any) is found to be
test-equivalent will be provided to users.

####  5.1.2. Evaluation metrics

We use _prefect prediction_ (Tufano et al., 2019a; Thongtanunam et al., 2022)
and CodeBLEU (Ren et al., 2020) to evaluate the effectiveness of each
learning-based baseline. The first metric quantifies the ratio of generated
programs that match the test samples’ ground truth (i.e., the developer-
implemented after-simplification version). The second metric measures the
similarity of the generated code to the ground truth. Prior study (Ren et al.,
2020) showed that the CodeBLEU metric better correlates with developers’
perception of code similarity than the BLEU metric. Both metrics are commonly
used by learning-based approaches to assess the quality of the generated
programs.

####  5.1.3. Baselines

We compare SimpT5 with the following approaches:

Ideal Delta debugging (IDD). As there many variants of delta debugging (Wang
et al., 2021a; Zeller and Hildebrandt, 2002; Misherghi and Su, 2006), we adopt
the ideal version of delta debugging IDD as a strong representative of these
variants. Specifically, IDD (1) will only use deletions for transformations,
and (2) can select the _correct_ statements for deletions (whenever
simplifying the ground truth $G$ requires only pure deletions, IDD can produce
exactly the same program as $G$). IDD represents deletion-based approaches.

JDeodorant. This is auto-refactoring tool (Tsantalis et al., 2018a) introduced
in Section 3.4.3. We use JDeodorant to represent rule-based approaches.

TufanoNMT. This is an NMT-based sequence-to-sequence transformation model
(Tufano et al., 2019a) . It tokenizes the input program into a sequence and
translates the sequence to a fixed code sequence.

AutoTransform. This method leverages a BPE scheme to handle new tokens and a
Transformer-based NMT architecture to handle longer sequences (Thongtanunam et
al., 2022).

Vanilla transformer. As we are the first to study the program simplification
task, and other baselines are not specifically designed for this task, we also
train a vanilla transformer from scratch on our whole dataset by reusing the
parameter setting in prior work (Thongtanunam et al., 2022).

###  5.2. [RQ5] Comparison with Prior Techniques

Table 5. Experimental results of deep-learning-based baselines

Benchmark Code Rep. TufanoNMT AutoTransform Vanilla Transformer SimpT5 PP
CodeBLEU PP CodeBLEU PP CodeBLEU PP CodeBLEU #/% mean median st. dev. #/% mean
median st. dev. #/% mean median st. dev. #/% mean median st. dev. Whole
(#9508) Raw 10/0.11 0.450 0.423 0.205 0/0.00 0.094 0.060 0.093 335/3.52 0.801
0.828 0.148 1842/19.37 0.856 0.882 0.136 Localized 14/0.15 0.411 0.385 0.199
0/0.00 0.084 0.053 0.088 2738/28.80 0.867 0.911 0.149 2827/29.73 0.878 0.911
0.128 Valid (#404) Raw 0/0.00 0.460 0.449 0.195 0/0.00 0.086 0.053 0.089
2/0.50 0.317 0.302 0.172 64/15.84 0.849 0.873 0.132 Localized 0/0.00 0.425
0.397 0.196 0/0.00 0.086 0.052 0.092 2/0.50 0.386 0.396 0.199 123/30.45 0.880
0.910 0.124

Table 5 shows the results for all the learning-based approaches. Compared to
TufanoNMT and AutoTransform, SimpT5 produces the greatest number of perfect
predictions (around 30%) and more similar code with the perfect predictions
(higher value of CodeBLEU). Among all baselines, we also observe that the
effectiveness of the Vanilla Transformer with localization is similar to
SimpT5 with localization (median CodeBLEU=0.911).

Table 6. Comparison results with IDD and JDeodorant Benchmark | Perfect Prediction (#/%)
---|---
IDD | JDeodorant | SimpT5
Whole(#9508) | 1913/20.12 | - | 2827/29.73
Valid(#404) | 82/20.30 | 0/0.00 | 123/30.45

For IDD and JDeodorant, we calculate the total number of perfect predictions
generated. We did not run JDeodorant in the whole dataset as it requires
compilation. Table 6 shows the results for the two approaches. Overall, SimpT5
outperforms IDD and JDeodorant by generating the greatest number of perfect
predictions. As JDeodorant only supported limited types of transformations,
our experiment shows that this rule-based approach did not generate any
perfect prediction for the _valid_ dataset. Listing 7 (ppe, [n. d.]) shows a
perfect prediction generated by SimpT5 where other baselines fail to generate
the perfect prediction. In this example, SimpT5 applys “Simplify method
return” transformation for simplification, which inlines the variable
declaration into the method return, resulting in shorter lines of code.

⬇

1 public Collection<AuditRequestLog> getAuditRequestLogs() {

2- Collection<AuditRequestLog> newList = repository.findAll();

3- return newList;

4+ return repository.findAll();

5 }

Listing 7: A SimpT5 generated perfect prediction example

###  5.3. [RQ6] Simplified Line localization

To investigate the effectiveness of the simplified line localization step in
SimpT5, we evaluate the number of perfect predictions generated by SimpT5 with
(_Localized_) and without (_Raw_) simplified line localization. Overall, we
can observe from _Localized_ and _Raw_ columns in Table 5 and Table 7 that
simplification line localization helps to guide SimpT5 in generating more
perfect predictions and increasing the diversity of the transformation types
used. Notably, without localization, SimpT5 can only generate 64 perfect
predictions but can generate 59 (92%) more perfect predictions after adding
simplified line localization. Listing 8 (for, [n. d.]) gives an example
showing the differences between program generated with and without line
localization. Without simplified line localization, SimpT5 would remove all
the System.out.println() in the original method. With the line localization
step in SimpT5 that marks the first two lines, SimpT5 can focus on simplifying
these two lines with “Use foreach in loop iteration” transformation, leads to
the generation of the perfect prediction. This example shows that simplified
line localization guides SimpT5 into generating more diverse transformation.

⬇

1- <original>for(int i = 0; i < numbers.size(); i++) {</original>

2- <original>Integer currentNum = numbers.get(i);</original>

3+ <simplified>for(Integer currentNum : numbers) {</simplified>

4 Integer otherNum = map.get(2020 - currentNum);

5 if (otherNum != null) {

6 System.out.println("this num = " + currentNum);

7 System.out.println("other num = " + otherNum);

8 int result = otherNum * currentNum;

9 System.out.println("result = " + result);

10 return result; } }

Listing 8: Effectiveness of simplified line localization

###  5.4. [RQ7] Types of Transformations Used

Table 7. Diversity of transformation types in perfect predictions in the
_valid_ dataset

Tool Transformation Type (type (#case with a specific type)) Total (#type;
#case) Raw Localized Raw Localized Tufano - - - - AutoTransform - - - -
Vanilla Transformer T3 (1), T1.1 (1) T3 (1), T1.1 (1) 2; 2 2; 2 SimpT5 T3
(27), T1.1 (14), T6.1 (5), T2.2 (4), T5.1 (3), T2.1 (2), T7.2 (2), T7.6 (2),
T1.3 (2), T1.9 (1), T1.6 (1), T7.5 (1) T3 (72), T1.1 (17), T2.2 (7), T1.10
(6), T5.1 (6), T1.3 (4), T2.1 (2), T6.1 (2),T7.6 (2), T7.2 (1), T1.9 (1), T1.6
(1), T7.5 (1), T4.1 (1) 12; 64 14; 123

To investigate the diversity of the generated simplifications, we manually
analyzed the types of transformation in the generated perfect predictions by
the deep learning baselines (we did not evaluate the diversity of $DD^{I}$ and
JDeodorant as these tools can only support the limited type of
transformations). The first two authors of this paper independently checked
the transformations; then, they held a meeting to resolve any disagreement.
Table 7 shows the distribution of the transformation types in perfect
predictions generated by the deep learning baselines. In the “Transformation
Type” columns, we use the labels in Table 2 to refer to the same
transformation type discovered in our study, whereas the last two columns
represent the total number of transformation types (#type) used and the total
number of perfect predictions generated by each approach for the _valid_
dataset. Overall, SimpT5 generates the highest number of perfect predictions
using the most diverse set of transformations compared to other baselines.
Specifically, it uses 12 (without localization) and 14 (with localization)
different types of transformations to generate the simplified programs. We
also observe that TufanoNMT uses only deletion in both of the correctly
generated simplified programs, making this baseline similar to $DD^{I}$, which
performs only deletion correctly. As we observe that all automatically
generated programs can be categorized using our taxonomy, this shows that _our
taxonomy of simplification is general._

###  5.5. [RQ8] Quality of the Generated Programs

To evaluate the quality of the generated programs in the _valid_ dataset, we
calculate _compilation passing rate and tests passing rate_ , which quantifies
the ratio of the generated simplified java programs that are test-equivalent.
We replace the original method with the simplified method, then compile the
whole project and run the test suites. Table 8 shows the compilation success
ratio and test-equivalent ratio on our valid dataset for each deep-learning-
based baseline. Overall, the programs generated by SimpT5 are of higher
quality with respect to compilation passing rate and test passing rate.
Specifically, SimpT5 performs better with line localization, which is almost
double the ratio with respect to compilation passing rate (35.40%) and tests
passing rate (31.19%). Compared to other baselines, SimpT5 could generate
simplified programs that are more likely to have the right syntax and keep the
original semantics.

We also measure the quality of the simplified programs generated by SimpT5
from three other metrics: SLOC (Source Lines of Code), Cyclomatic Complexity,
and Readability. We measure the perfect predictions and semantic-equivalent
simplifications generated by SimpT5. As other baselines only generate very few
numbers of perfect predictions and semantic-equivalent (e.g., Vanilla
Transformer can only generate 4 semantic-equivalent program and zero perfect
prediction), we compare our tool with the ideal delta debugging (IDD) only,
which generates 82 (20.30%) perfect predictions. Table 9 provides the results
with respect to these three metrics. Specifically, for SLOC, SimpT5 performs
better on the raw data, and the generated semantic-equivalent simplifications
achieve the highest reduction ratio (18.13%) on the average number of SLOC.

Table 8. Quality of generated programs

Tool Compilation Success #/% Tests-equivalent #/% Raw Localized Raw Localized
Tufano 22/5.45 10/6.19 16/3.96 7/1.73 AutoTransform 2/0.50 2/0.50 2/0.50
2/0.50 Vanilla Transformer 4/0.99 4/0.99 4/0.99 4/0.99 SimpT5 70/17.33
143/35.40 63/15.59 126/31.19

Table 9. Simplification results with respect to SLOC, Complexity, and
Readability

Metric Type IDD SimpT5 Raw Localized PP PP SE PP SE O S O S O S O S O S SLOC
mean 14.66 12.66 (-13.64%) 8.77 7.18 (-18.13%) 10.65 9.13 (-14.27%) 12.12
10.19 (-15.92%) 12.39 10.23 (-17.43%) median 13.00 10.00 (-23.08%) 8.00 6.50
(-18.75%) 10.00 8.00 (-20.00%) 11.00 8.00 (-27.27%) 11.00 9.00 (-18.18%) st.
dev. 7.88 7.45 4.39 4.18 5.99 5.69 6.57 6.36 6.76 6.46 Complexity mean 3.06
2.83 (-7.52%) 1.95 1.91 (-2.05%) 2.56 2.35 (-8.20%) 2.63 2.35 (-10.65%) 3.13
2.63 (-15.97%) median 2.0 2.0 (-0.00%) 1.00 1.00 (-0.00%) 2.00 2.00 (-0.00%)
2.00 2.00 (-0.00%) 2.50 2.00 (-20.00%) st. dev. 2.61 2.44 1.43 1.44 1.70 1.52
2.07 1.83 2.36 2.02 Readability mean 2.48 2.26 (-8.87%) 1.09 1.05 (-3.67%)
2.11 1.87 (-11.37%) 2.04 1.76 (-13.73%) 2.90 2.37 (-18.28%) median 1.0 1.0
(-0.00%) 0.50 0.00 (-100%) 1.00 1.00 (-0.00%) 1.00 1.00 (-0.00%) 2.00 1.00
(-50.00%) st. dev. 3.36 3.27 1.34 1.36 2.60 2.26 2.90 2.77 3.68 3.33

  * •

SLOC: source lines of code; PP: perfect prediction; SE: semantic-equivalent;
O: original program; S: simplified program.

##  6\. Threats to Validity

We identify the following threats to validity of this paper:

External. The set of program transformations used by developers found in our
study merely represents transformations that are frequently occurred in these
commits (i.e., we do not claim that our identified set is a “complete” set).
We mitigate this by studying developer-induced program simplification from two
perspectives: (1) PRs in the study, and (2) commits in our mined dataset. For
verifiability, we also release the generated programs. As our study and
evaluation only focus on Java open-source projects, the findings may not
generalize beyond Java and other closed-source projects.

Internal. Our scripts and tool may have bugs that can affect our results. To
mitigate this, we share our results, dataset and tool.

Conclusion. Conclusion threats include (1) overfitting of our dataset and (2)
subjectivity of manual analysis. We minimize (1) by ensuring that the training
and testing dataset use data from different projects. We mitigate (2) by
cross-validating between two annotators.

##  7\. Implication

Based on our study and evaluation, we discuss the implications for developers
and researchers.

Implication for Developers. Our study identifies a set of commonly used
program transformations for developer-induced program simplification and
developers’ motivations. Based on our study’s two most common transformations
(Extract method and “Replace with equivalent API”), we realized that
developers tend to perform simplification by introducing new methods or
reusing existing API (Finding 1). Meanwhile, despite sharing the same goals of
obtaining a simplified program, some IDE-supported simplifications need to be
invoked under different menus (Finding 1). As IDE users have expressed
difficulty in finding these transformations (org, [n. d.]; dia, [n. d.]), IDE
plugin developers should consider _enhancing the usability of the by
aggregating all transformations_ that share the same purpose of
simplification. For example, most modern IDE supports “Remove unused imports”
as an “Organize imports” feature, whereas “Use diamond operator” is available
only under “Java inspection” in IntelliJ. Our study of the motivations behind
developer-induced program simplification suggests developers to _use existing
static metrics to ensure the quality of the manually crafted simplified
programs_ (Finding 2). Moreover, although most simplification types are
covered by existing refactoring types (Finding 3), prior auto-refactoring
tools only support limited types (Finding 4). This means that developers can
only use prior auto-refactoring tools (e.g., JDeodorant) for the few supported
types. Hence, we propose SimpT5 to automate developer-induced program
simplification.

Implication for Researchers. Our study and proposed program simplification
framework lay the foundation for research in three promising directions.
First, our study _provides the key criteria that drive the design of future
automated tools for developer-induced program simplification_. Such tools
should (1) contain a richer set of program transformations (Finding 1), (2)
incorporate language-specific features (Finding 1), (3) incorporate prior
static metrics (e.g., SLOCs, readability and cyclomatic complexity) for
checking the quality of the generated code (Finding 2). Our proposed framework
and the SimpliBench dataset lay the first step in promoting future research
towards this direction. Second, _there exists limitations of adapting existing
refactoring detection and auto-refactoring tools for detecting and automating
developer-induced program simplification_. As developer-induced program
simplification involves diverse types of program transformations, our study
reveals that several frequently used transformations, e.g., replacing with
equivalent API and simplifying expression, have not been automated (Finding
1). To enhance the usability of IDE-supported simplifications, it is
worthwhile to investigate better UI design to help users to invoke different
transformations that share the same goals of simplifications (Finding 3).
Within the supported refactoring types, refactoring detection and auto-
refactoring tools fail to detect them due to the limitations in the hand-
crafted rules used for detection (Finding 4) and limited types of refactoring
supported by auto-refactoring tools (Finding 5). Third, _our taxonomy of
developer-induced program simplification serves as preliminary studies for
motivating future research on using a richer set of transformations for
improving deletion-based approaches_ (e.g., program reduction and debloating).
As deletion-based approaches have been applied in many domains (Section 2), it
is worthwhile future work to investigate how to incorporate more human-like
transformations to further improve these deletion-based techniques. For
example, instead of relying on genetic operators (mutation and crossover),
incorporating our simplifications to remove code bloat in genetic
programmingcould help generate more diverse programs.

##  8\. Conclusion

We present the first study of developer-induced program simplification in OSS
projects, focusing on the transformations types, developers’ motivations, and
the transformations covered by existing refactoring types. Our study reveals
gaps in applying existing approaches for automating developer-induced program
simplification and outlines the criteria for designing automatic
simplification techniques. Based on our study, we propose SimpT5, an automated
simplification framework that learns from our dataset SimpliBench using
simplified line localization, and a checker. Our experiment shows that SimpT5
is more effective than prior approaches.

## Data Availability

The data and code are available at (dat, [n. d.]).

## References

  * (1)
  * dat ([n. d.]) [n. d.].  _Artifact_.  https://anonymous.4open.science/r/Automated-Program-Simplification-CCC6/
  * dia ([n. d.]) [n. d.].  _Convert existing generics to diamond syntax_.  https://stackoverflow.com/questions/6796545/convert-existing-generics-to-diamond-syntax
  * for ([n. d.]) [n. d.].  _Foreach example_.  https://github.com/ggavriilidis/adventOfCodeChallenge2020/commit/e56363b6d409e491506b084e7319c9bc82895cd6
  * Hug ([n. d.]) [n. d.].  _Huggingface_.  https://huggingface.co/models
  * inl ([n. d.]) [n. d.].  _Inline variable example commit link_.  https://github.com/discoStar711/job-finder/pull/10/commits/4559aa19ca2228a0ebb7242636751c5be4ba42e3
  * org ([n. d.]) [n. d.].  _IntelliJ Organize Imports_.  https://stackoverflow.com/questions/8608710/intellij-organize-imports
  * Ope ([n. d.]) [n. d.].  _OpenPrompt_.  https://github.com/thunlp/OpenPrompt
  * ppe ([n. d.]) [n. d.].  _Perfect prediction example_.  https://github.com/Verdoso/VersioningDemo/commit/6afa0093e24fbb26f4597fdbbcef22714e3d4aa8
  * Agrawal and Horgan (1990) Hiralal Agrawal and Joseph R Horgan. 1990.  Dynamic program slicing.  _ACM SIGPlan Notices_ 25, 6 (1990), 246–256.
  * Alizadeh et al. (2019) Vahid Alizadeh, Mohamed Amine Ouali, Marouane Kessentini, and Meriem Chater. 2019.  RefBot: intelligent software refactoring bot. In _2019 34th IEEE/ACM international conference on automated software engineering (ASE)_. 823–834.
  * AlOmar et al. (2019) Eman AlOmar, Mohamed Wiem Mkaouer, and Ali Ouni. 2019.  Can refactoring be self-affirmed? an exploratory study on how developers document their refactoring activities in commit messages. In _2019 IEEE/ACM 3rd International Workshop on Refactoring (IWoR)_. 51–58.
  * AlOmar et al. (2021) Eman Abdullah AlOmar, Anthony Peruma, Mohamed Wiem Mkaouer, Christian Newman, Ali Ouni, and Marouane Kessentini. 2021.  How we refactor and how we document it? On the use of supervised machine learning algorithms to classify refactoring documentation.  _Expert Systems with Applications_ 167 (2021), 114176.
  * Azeem et al. (2019) Muhammad Ilyas Azeem, Fabio Palomba, Lin Shi, and Qing Wang. 2019.  Machine learning techniques for code smell detection: A systematic literature review and meta-analysis.  _Information and Software Technology_ (2019).
  * Bansiya and Davis (2002) Jagdish Bansiya and Carl G. Davis. 2002.  A hierarchical model for object-oriented design quality assessment.  _IEEE Transactions on software engineering_ 28, 1 (2002), 4–17.
  * Becker et al. (1999) Paul Becker, Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. 1999.  _Refactoring: improving the design of existing code_.  Addison-Wesley Professional.
  * Binkley et al. (2005) Dave Binkley, Mariano Ceccato, Mark Harman, Filippo Ricca, and Paolo Tonella. 2005.  Automated refactoring of object oriented code into aspects. In _21st IEEE International Conference on Software Maintenance (ICSM’05)_. 27–36.
  * Binkley et al. (2014) David Binkley, Nicolas Gold, Mark Harman, Syed Islam, Jens Krinke, and Shin Yoo. 2014.  ORBS: Language-independent program slicing. In _Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering_. 109–120.
  * Binkley et al. (2013) David Binkley, Nicolas Gold, Mark Harman, Jens Krinke, and Shin Yoo. 2013.  Observation-based slicing.  _RN_ (2013).
  * Brito and Valente (2021) Rodrigo Brito and Marco Tulio Valente. 2021.  RAID: Tool support for refactoring-aware code reviews. In _2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC)_. 265–275.
  * Buse and Weimer (2008) Raymond PL Buse and Westley R Weimer. 2008.  A metric for software readability. In _Proceedings of the 2008 international symposium on Software testing and analysis_.
  * Campbell (2018) G Ann Campbell. 2018.  Cognitive complexity: An overview and evaluation. In _Proceedings of the 2018 international conference on technical debt_. 57–58.
  * Cruzes and Dyba (2011) Daniela S Cruzes and Tore Dyba. 2011.  Recommended steps for thematic synthesis in software engineering. In _2011 international symposium on empirical software engineering and measurement_. 275–284.
  * Dig et al. (2009) Danny Dig, John Marrero, and Michael D Ernst. 2009.  Refactoring sequential Java code for concurrency via concurrent libraries. In _2009 IEEE 31st International Conference on Software Engineering_.
  * Ebert et al. (2016) Christof Ebert, James Cain, Giuliano Antoniol, Steve Counsell, and Phillip Laplante. 2016.  Cyclomatic complexity.  _IEEE software_ 33, 6 (2016), 27–29.
  * Fan et al. (2023) Zhiyu Fan, Xiang Gao, Martin Mirchev, Abhik Roychoudhury, and Shin Hwei Tan. 2023.  Automated Repair of Programs from Large Language Models. In _Proceedings of the 45th International Conference on Software Engineering_ (Melbourne, Victoria, Australia) _(ICSE ’23)_. IEEE Press, 1469–1481.  https://doi.org/10.1109/ICSE48619.2023.00128
  * Fontana et al. (2013) Francesca Arcelli Fontana, Marco Zanoni, Alessandro Marino, and Mika V Mäntylä. 2013.  Code smell detection: Towards a machine learning-based approach. In _2013 IEEE international conference on software maintenance_.
  * Fu et al. (2022) Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung. 2022.  VulRepair: a T5-based automated software vulnerability repair. In _Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering_. 935–947.
  * Ge et al. (2012) Xi Ge, Quinton L DuBose, and Emerson Murphy-Hill. 2012.  Reconciling manual and automatic refactoring. In _2012 34th International Conference on Software Engineering (ICSE)_. 211–221.
  * Gousios and Spinellis (2012) Georgios Gousios and Diomidis Spinellis. 2012.  GHTorrent: GitHub’s data from a firehose. In _2012 9th IEEE Working Conference on Mining Software Repositories (MSR)_. 12–21.
  * Gu et al. (2021) Yuxian Gu, Xu Han, Zhiyuan Liu, and Minlie Huang. 2021.  Ppt: Pre-trained prompt tuning for few-shot learning.  _arXiv preprint arXiv:2109.04332_ (2021).
  * Gyori et al. (2013) Alex Gyori, Lyle Franklin, Danny Dig, and Jan Lahoda. 2013.  Crossing the gap from imperative to functional programming through refactoring. In _Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering_. 543–553.
  * Hammoudi et al. (2015) Mouna Hammoudi, Brian Burg, Gigon Bae, and Gregg Rothermel. 2015.  On the use of delta debugging to reduce recordings and facilitate debugging of web applications. In _Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering_. 333–344.
  * Harman and Danicic (1995) Mark Harman and Sebastian Danicic. 1995.  Using program slicing to simplify testing.  _Software Testing, Verification and Reliability_ (1995).
  * He et al. (2021) Xincheng He, Lei Xu, Xiangyu Zhang, Rui Hao, Yang Feng, and Baowen Xu. 2021.  Pyart: Python api recommendation in real-time. In _2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)_. 1634–1645.
  * Hegedűs et al. (2018) Péter Hegedűs, István Kádár, Rudolf Ferenc, and Tibor Gyimóthy. 2018.  Empirical evaluation of software maintainability based on a manually validated refactoring dataset.  _Information and Software Technology_ (2018).
  * Heo et al. (2018) Kihong Heo, Woosuk Lee, Pardis Pashakhanloo, and Mayur Naik. 2018.  Effective program debloating via reinforcement learning. In _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security_.
  * Hodován and Kiss (2016) Renáta Hodován and Ákos Kiss. 2016.  Modernizing hierarchical delta debugging. In _Proceedings of the 7th International Workshop on Automating Test Case Design, Selection, and Evaluation_. 31–37.
  * Hodován et al. (2017) Renáta Hodován, Ákos Kiss, and Tibor Gyimóthy. 2017.  Coarse hierarchical delta debugging. In _2017 IEEE international conference on software maintenance and evolution (ICSME)_.
  * Huang et al. (2018) Qiao Huang, Xin Xia, Zhenchang Xing, David Lo, and Xinyu Wang. 2018.  API method recommendation without worrying about the task-API knowledge gap. In _Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering_. 293–304.
  * Jalbert and Sen (2010) Nicholas Jalbert and Koushik Sen. 2010.  A trace simplification technique for effective debugging of concurrent programs. In _Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations of software engineering_. 57–66.
  * Jensen and Cheng (2010) Adam C Jensen and Betty HC Cheng. 2010.  On the use of genetic programming for automated refactoring and the introduction of design patterns. In _Proceedings of the 12th annual conference on Genetic and evolutionary computation_. 1341–1348.
  * Jiang et al. (2017) Bo Jiang, Yuxuan Wu, Teng Li, and Wing Kwong Chan. 2017.  Simplydroid: efficient event sequence simplification for Android application. In _2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE)_. 297–307.
  * Jiang et al. (2019) Lin Jiang, Hui Liu, and He Jiang. 2019.  Machine learning based recommendation of method names: How far are we. In _2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE)_.
  * Jiang et al. (2021) Nan Jiang, Thibaud Lutellier, and Lin Tan. 2021.  Cure: Code-aware neural machine translation for automatic program repair. In _2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)_. 1161–1173.
  * Kádár et al. (2016) István Kádár, Péter Hegedus, Rudolf Ferenc, and Tibor Gyimóthy. 2016.  A code refactoring dataset and its assessment regarding software maintainability. In _2016 IEEE 23rd International conference on software analysis, Evolution, and Reengineering (SANER)_ , Vol. 1. 599–603.
  * Karakati and Thirumaaran (2022) Chitti Babu Karakati and Sethukarasi Thirumaaran. 2022.  Software code refactoring based on deep neural network-based fitness function.  _Concurrency and Computation: Practice and Experience_ (2022), e7531.
  * Kim et al. (2021) Dong Jae Kim, Nikolaos Tsantalis, Tse-Hsun Chen, and Jinqiu Yang. 2021.  Studying test annotation maintenance in the wild. In _2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)_. 62–73.
  * Kim et al. (2012) Miryung Kim, Thomas Zimmermann, and Nachiappan Nagappan. 2012.  A field study of refactoring challenges and benefits. In _Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering_. 1–11.
  * Kim et al. (2011) Sunghun Kim, Hongyu Zhang, Rongxin Wu, and Liang Gong. 2011.  Dealing with noise in defect prediction. In _Proceedings of the 33rd International Conference on Software Engineering_. 481–490.
  * Le Goues et al. (2012) Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2012.  GenProg: A generic method for automatic software repair.  _Software Engineering, IEEE Transactions on_ 38, 1 (2012), 54–72.
  * Liu et al. (2022) Fang Liu, Ge Li, Zhiyi Fu, Shuai Lu, Yiyang Hao, and Zhi Jin. 2022.  Learning to recommend method names with global context. In _Proceedings of the 44th International Conference on Software Engineering_.
  * Liu et al. (2019a) Hui Liu, Jiahao Jin, Zhifeng Xu, Yanzhen Zou, Yifan Bu, and Lu Zhang. 2019a.  Deep learning based code smell detection.  _IEEE transactions on Software Engineering_ (2019).
  * Liu et al. (2019b) Kui Liu, Anil Koyuncu, Dongsun Kim, and Tegawendé F Bissyandé. 2019b.  TBar: Revisiting template-based automated program repair. In _Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis_. 31–42.
  * Lu and Debray (2012) Gen Lu and Saumya Debray. 2012.  Automatic simplification of obfuscated JavaScript code: A semantics-based approach. In _2012 IEEE Sixth International Conference on Software Security and Reliability_. 31–40.
  * Lutellier et al. (2020) Thibaud Lutellier, Hung Viet Pham, Lawrence Pang, Yitong Li, Moshi Wei, and Lin Tan. 2020.  Coconut: combining context-aware neural translation models using ensemble for program repair. In _Proceedings of the 29th ACM SIGSOFT international symposium on software testing and analysis_. 101–114.
  * Madden (2020) Neil Madden. 2020.  _API security in action_.  Simon and Schuster.
  * McCabe (1976) Thomas J McCabe. 1976.  A complexity measure.  _IEEE Transactions on software Engineering_ 4 (1976), 308–320.
  * Meng et al. (2015) Na Meng, Lisa Hua, Miryung Kim, and Kathryn S McKinley. 2015.  Does automated refactoring obviate systematic editing?. In _2015 IEEE/ACM 37th IEEE International Conference on Software Engineering_ , Vol. 1. 392–402.
  * Misherghi and Su (2006) Ghassan Misherghi and Zhendong Su. 2006.  HDD: hierarchical delta debugging. In _Proceedings of the 28th international conference on Software engineering_.
  * Muñoz Barón et al. (2020) Marvin Muñoz Barón, Marvin Wyrich, and Stefan Wagner. 2020.  An empirical validation of cognitive complexity as a measure of source code understandability. In _Proceedings of the 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)_. 1–12.
  * Murphy-Hill and Black (2008) Emerson Murphy-Hill and Andrew P Black. 2008.  Breaking the barriers to successful refactoring: observations and tools for extract method. In _Proceedings of the 30th international conference on Software engineering_.
  * Nguyen et al. (2019) Tam The Nguyen, Phong Minh Vu, and Tung Thanh Nguyen. 2019.  Api misuse correction: A statistical approach.  _arXiv preprint arXiv:1908.06492_ (2019).
  * Nievergelt (1965) Jürg Nievergelt. 1965.  On the automatic simplification of computer programs.  _Commun. ACM_ 8, 6 (1965), 366–370.
  * Oliveira et al. (2023) Daniel Oliveira, Wesley KG Assunção, Alessandro Garcia, Ana Carla Bibiano, Márcie Ribeiro, Rohit Gheyi, and Baldoino Fonseca. 2023.  The untold story of code refactoring customizations in practice. In _2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE)_.
  * Ouni et al. (2016) Ali Ouni, Marouane Kessentini, Houari Sahraoui, Katsuro Inoue, and Kalyanmoy Deb. 2016.  Multi-Criteria Code Refactoring Using Search-Based Software Engineering: An Industrial Case Study.  _ACM Trans. Softw. Eng. Methodol._ 25, 3, Article 23 (jun 2016), 53 pages.  https://doi.org/10.1145/2932631
  * Paixão et al. (2020) Matheus Paixão, Anderson Uchôa, Ana Carla Bibiano, Daniel Oliveira, Alessandro Garcia, Jens Krinke, and Emilio Arvonio. 2020.  Behind the intents: An in-depth empirical study on software refactoring in modern code review. In _Proceedings of the 17th International Conference on Mining Software Repositories_. 125–136.
  * Parsa et al. (2023) Saeed Parsa, Morteza Zakeri-Nasrabadi, Masoud Ekhtiarzadeh, and Mohammad Ramezani. 2023.  Method name recommendation based on source code metrics.  _Journal of Computer Languages_ (2023).
  * Pecorelli et al. (2020) Fabiano Pecorelli, Dario Di Nucci, Coen De Roover, and Andrea De Lucia. 2020.  A large empirical assessment of the role of data balancing in machine-learning-based code smell detection.  _Journal of Systems and Software_ (2020).
  * Peruma et al. (2022) Anthony Peruma, Steven Simmons, Eman Abdullah AlOmar, Christian D Newman, Mohamed Wiem Mkaouer, and Ali Ouni. 2022.  How do i refactor this? An empirical study on refactoring trends and topics in Stack Overflow.  _Empirical Software Engineering_ 27, 1 (2022), 1–43.
  * Posnett et al. (2011) Daryl Posnett, Abram Hindle, and Premkumar Devanbu. 2011.  A simpler model of software readability. In _Proceedings of the 8th working conference on mining software repositories_.
  * Qian et al. (2019) Chenxiong Qian, Hong Hu, Mansour Alharthi, Pak Ho Chung, Taesoo Kim, and Wenke Lee. 2019.  $\\{$RAZOR$\\}$: A framework for post-deployment software debloating. In _28th USENIX security symposium (USENIX Security 19)_.
  * Rabin et al. (2022) Md Rafiqul Islam Rabin, Aftab Hussain, and Mohammad Amin Alipour. 2022.  Syntax-guided program reduction for understanding neural code intelligence models. In _Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming_. 70–79.
  * Rahman et al. (2016) Mohammad Masudur Rahman, Chanchal K Roy, and David Lo. 2016.  Rack: Automatic api recommendation using crowdsourced knowledge. In _2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER)_ , Vol. 1. 349–359.
  * Rathee and Chhabra (2022) Amit Rathee and Jitender K Chhabra. 2022.  Metrics for reusability of java language components.  _Journal of King Saud University-Computer and Information Sciences_ 34, 8 (2022), 5533–5551.
  * Ren et al. (2020) Shuo Ren, Daya Guo, Shuai Lu, Long Zhou, Shujie Liu, Duyu Tang, Neel Sundaresan, Ming Zhou, Ambrosio Blanco, and Shuai Ma. 2020.  Codebleu: a method for automatic evaluation of code synthesis.  _arXiv preprint arXiv:2009.10297_ (2020).
  * Sennrich et al. (2015) Rico Sennrich, Barry Haddow, and Alexandra Birch. 2015.  Neural machine translation of rare words with subword units.  _arXiv preprint arXiv:1508.07909_ (2015).
  * Sharma et al. (2021) Tushar Sharma, Vasiliki Efstathiou, Panos Louridas, and Diomidis Spinellis. 2021.  Code smell detection by deep direct-learning and transfer-learning.  _Journal of Systems and Software_ (2021).
  * Silva et al. (2016) Danilo Silva, Nikolaos Tsantalis, and Marco Tulio Valente. 2016.  Why we refactor? confessions of github contributors. In _Proceedings of the 2016 24th acm sigsoft international symposium on foundations of software engineering_.
  * Sitthi-Amorn et al. (2011) Pitchaya Sitthi-Amorn, Nicholas Modly, Westley Weimer, and Jason Lawrence. 2011.  Genetic Programming for Shader Simplification.  _ACM Trans. Graph._ 30, 6 (dec 2011), 1–12.  https://doi.org/10.1145/2070781.2024186
  * Sun et al. (2018) Chengnian Sun, Yuanbo Li, Qirun Zhang, Tianxiao Gu, and Zhendong Su. 2018.  Perses: Syntax-guided program reduction. In _Proceedings of the 40th International Conference on Software Engineering_. 361–371.
  * Thongtanunam et al. (2022) Patanamon Thongtanunam, Chanathip Pornprasit, and Chakkrit Tantithamthavorn. 2022.  Autotransform: Automated code transformation to support modern code review process. In _Proceedings of the 44th International Conference on Software Engineering_.
  * Tsantalis et al. (2018a) Nikolaos Tsantalis, Theodoros Chaikalis, and Alexander Chatzigeorgiou. 2018a.  Ten years of JDeodorant: Lessons learned from the hunt for smells. In _2018 IEEE 25th international conference on software analysis, evolution and reengineering (SANER)_.
  * Tsantalis et al. (2020) Nikolaos Tsantalis, Ameya Ketkar, and Danny Dig. 2020.  RefactoringMiner 2.0.  _IEEE Transactions on Software Engineering_ (2020).
  * Tsantalis et al. (2018b) Nikolaos Tsantalis, Matin Mansouri, Laleh M. Eshkevari, Davood Mazinanian, and Danny Dig. 2018b.  Accurate and Efficient Refactoring Detection in Commit History. In _Proceedings of the 40th International Conference on Software Engineering_ (Gothenburg, Sweden) _(ICSE ’18)_. ACM, New York, NY, USA, 483–494.  https://doi.org/10.1145/3180155.3180206
  * Tsantalis et al. (2017) Nikolaos Tsantalis, Davood Mazinanian, and Shahriar Rostami. 2017.  Clone refactoring with lambda expressions. In _2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)_. 60–70.
  * Tufano et al. (2019a) Michele Tufano, Jevgenija Pantiuchina, Cody Watson, Gabriele Bavota, and Denys Poshyvanyk. 2019a.  On learning meaningful code changes via neural machine translation. In _2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)_.
  * Tufano et al. (2019b) Michele Tufano, Cody Watson, Gabriele Bavota, Massimiliano Di Penta, Martin White, and Denys Poshyvanyk. 2019b.  An empirical study on learning bug-fixing patches in the wild via neural machine translation.  _ACM Transactions on Software Engineering and Methodology (TOSEM)_ 28, 4 (2019), 1–29.
  * Wang et al. (2022) Chaozheng Wang, Yuanhang Yang, Cuiyun Gao, Yun Peng, Hongyu Zhang, and Michael R Lyu. 2022.  No more fine-tuning? an experimental evaluation of prompt tuning in code intelligence. In _Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering_. 382–394.
  * Wang et al. (2021a) Guancheng Wang, Ruobing Shen, Junjie Chen, Yingfei Xiong, and Lu Zhang. 2021a.  Probabilistic delta debugging. In _Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering_.
  * Wang et al. (2021b) Yue Wang, Weishi Wang, Shafiq Joty, and Steven CH Hoi. 2021b.  Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation.  _arXiv preprint arXiv:2109.00859_ (2021).
  * Washizaki et al. (2004) Hironori Washizaki, Hirokazu Yamamoto, and Yoshiaki Fukazawa. 2004.  A metrics suite for measuring reusability of software components. In _Proceedings. 5th International Workshop on enterprise networking and computing in healthcare industry (IEEE Cat. No. 03EX717)_. 211–223.
  * Wong et al. (2023) W Eric Wong, Hira Agrawal, and Xiangyu Zhang. 2023.  Slicing-Based Techniques for Software Fault Localization.  _Handbook of Software Fault Localization: Foundations and Advances_ (2023), 135–200.
  * Xu et al. (2023) Zhenyang Xu, Yongqiang Tian, Mengxiao Zhang, Gaosen Zhao, Yu Jiang, and Chengnian Sun. 2023.  Pushing the Limit of 1-Minimality of Language-Agnostic Program Reduction.  _Proceedings of the ACM on Programming Languages_ 7, OOPSLA1 (2023), 636–664.
  * Zeller (1999) Andreas Zeller. 1999.  Yesterday, My Program Worked. Today, It Does Not. Why?  _SIGSOFT Softw. Eng. Notes_ 24, 6 (Oct. 1999), 253–267.
  * Zeller and Hildebrandt (2002) Andreas Zeller and Ralf Hildebrandt. 2002.  Simplifying and Isolating Failure-Inducing Input.  _IEEE Trans. Softw. Eng._ 28, 2 (Feb. 2002), 183–200.  https://doi.org/10.1109/32.988498
  * Zhang et al. (2022) Jiyang Zhang, Sheena Panthaplackel, Pengyu Nie, Junyi Jessy Li, and Milos Gligoric. 2022.  Coditt5: Pretraining for source code and natural language editing. In _Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering_. 1–12.
  * Zhang (2013) Sai Zhang. 2013.  Practical semantic test simplification. In _2013 35th International Conference on Software Engineering (ICSE)_. 1173–1176.
  * Zhang et al. (2018) Tianyi Zhang, Ganesha Upadhyaya, Anastasia Reinhardt, Hridesh Rajan, and Miryung Kim. 2018.  Are code examples on an online q&a forum reliable? a study of api misuse on stack overflow. In _Proceedings of the 40th international conference on software engineering_. 886–896.
  * Zhu et al. (2021) Qihao Zhu, Zeyu Sun, Yuan-an Xiao, Wenjie Zhang, Kang Yuan, Yingfei Xiong, and Lu Zhang. 2021.  A syntax-guided edit decoder for neural program repair. In _Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering_. 341–353.