Pith. sign in

REVIEW 3 major objections 5 minor 91 references

Recommending Variable Names for Extract Local Variable Refactorings

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read VarNamer matches the developer's chosen name in 41.5% of extract-local-variable refactorings, beating Eclipse, IntelliJ IDEA, and Incoder by 52.6%, 40.7%, and 25% respectively.

desk verdict Solid, practical paper whose core result survives a fair comparison but whose abstract oversells the improvement by mixing denominators. read the letter →

arxiv 2507.00413 v1 pith:EOBLASEE submitted 2025-07-01 cs.SE

Taiming Wang , Hui Liu , Yuxia Zhang , Yanjie Jiang This is my paper
classification cs.SE
keywords extractlocalvariablerefactoringnamerecommendationhomogeneousreuseassociationruleminingFP-growthstaticanalysisuserstudy
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Extract local variable is one of the most common refactorings, yet the paper reports that in about 70% of cases the names suggested by Eclipse and IntelliJ IDEA differ from what developers actually choose. The paper introduces VarNamer, a tool that recommends a name for the newly extracted variable by reusing names of homogeneous variables (variables initialized by the same expression elsewhere in the same file) and by applying naming rules mined from 1.6 million real variable declarations. On 27,158 real refactorings VarNamer's exact-match precision is 41.5%, versus 27.2% for Eclipse, 29.5% for IntelliJ IDEA, and 33.2% for the Incoder language model; on the 21,766 cases where VarNamer makes a recommendation, the gap over the same baselines is 41.5% versus 32.4%, 34.5%, and 35.1%. A user study with 50 C++ refactorings reports 27.8% faster refactoring and 49.3% fewer edits to the suggested names, and the paper notes that key heuristics have been merged into Eclipse releases.

What carries the argument

The central object is the homogeneous variable: a variable whose initialization is identical to the expression being extracted. VarNamer's reuse component searches the enclosing Java file for such variables, applies a coarse-grained filter that deactivates reuse for universal initializations, then a fine-grained validator that builds a Variable Dependency Graph over the abstract syntax tree and computes structural similarity (Dice coefficient on AST node types) and literal similarity (normalized Levenshtein distance) between the statement using the new variable and statements using the homogeneous variable. The generation component aligns sub-tokens of variable names and initializations, replaces aligned tokens with a placeholder, and runs FP-growth to mine association rules, with minimum support 50 and confidence 0.8, that map method-call initializations to preferred name tokens. The selection component filters out Java keywords and names already in scope and prioritizes reused names over generated ones because reuse alone has higher precision, 80.3%.

What would settle it

Find refactorings, either in the dataset or in new commits, where the same extracted expression was named independently by different developers, such as parallel pull requests extracting the same expression, and measure how often their chosen names agree; if the agreement rate is well below VarNamer's 41.5% exact-match rate, part of the reported precision is matching an arbitrary single choice and a consensus-based ground truth should replace the commit author's name.

Watch

Extended reading notes

Core claim

VarNamer's central claim is that the name of an extracted local variable is already present in its surrounding code often enough that a static-analysis tool can match the developer's choice far more often than existing IDEs. The paper argues that the most reliable context is the homogeneous variable, a variable elsewhere with the same initialization, whose name can be reused after filtering out universal initializations like null, 0, 1, true, false, and new StringBuilder() and after validating statement- and method-level similarity. When no reusable name is reliable, VarNamer generates candidates from association rules mined over aligned sub-tokens of initializations and variable names, such as fetchX() or generateX() naming the noun after the verb and features.next() yielding feature. Combining reuse and generation, VarNamer reaches 41.5% exact-match precision on 21,766 recommendations from 27,158 real refactorings, and the paper reports 44.0% on a 50-case C++ dataset, concluding that the context-driven design transfers across languages.

Load-bearing premise

The evaluation treats the variable name the original developer chose in the refactoring commit as the one correct answer, so precision and coverage measure agreement with that single historical choice; if developer names for the same expression vary across people or contexts, the exact-match numbers would not directly measure name quality.

Editorial extensions

If this is right

  • If VarNamer's numbers hold, an IDE can accept the suggested name outright in over 40% of extract-local-variable refactorings, eliminating the renaming step that currently burdens developers in about 70% of cases.
  • Same-file homogeneous variables become a first-class context: the reuse component alone reaches 80.3% exact-match precision when it does recommend, so IDEs that ignore sibling methods can gain precision by searching the enclosing file.
  • The mined rules generalize the verb-stripping heuristics of Eclipse and IntelliJ IDEA, covering verbs like read, build, add, and parse, plus plural-receiver patterns like features.next() leading to feature, which closes much of the gap with those IDEs.
  • Because the C++ port achieves 44.0% precision versus Eclipse CDT's 12.5% on 50 real refactorings, the same context-and-rules design should transfer to other statically analyzable languages.
  • The user-study results imply that adopting VarNamer-style recommendation saves about a quarter of refactoring time and halves the edits developers make to suggested names.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Exact match to the original developer's name is a conservative lower bound on usefulness: a recommendation that is semantically equivalent but spelled differently, such as idx versus index, scores as a miss, so the real acceptance rate may be higher than 41.5%.
  • The same reuse idea could extend to extract method, extract constant, and renaming parameters or fields, where homogeneous occurrences with the same expression, type, or surrounding statements are equally detectable; the paper lists these as future work.
  • VarNamer's cheap heuristics make it an attractive first-stage candidate generator: an LLM reranker on top of its 21,766 recommendations could raise coverage without the 48-second per-case latency Incoder exhibits.
  • The 70% IDE-mismatch figure and the 49.3% edit reduction suggest that name suggestion quality, not refactoring mechanics, is the main remaining friction in automated extract-local-variable refactoring.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper introduces VarNamer, a tool that recommends variable names for extract local variable refactorings by combining reuse of names from homogeneous variables with naming rules mined from a large code corpus using FP-growth. The authors report an empirical study of useful naming contexts, an evaluation on 27,158 real-world Java refactorings, a smaller manually collected C++ evaluation, and a user study with six developers. The paper claims that VarNamer significantly increases the chance of exact name match by 52.6% compared with Eclipse and 40.7% compared with IntelliJ IDEA, and that the approach generalizes to C++ with comparable performance. The work also reports that several heuristic rules were merged into Eclipse.

Significance. The paper makes a practical contribution to refactoring tooling: some of its heuristics have been integrated into Eclipse, and the evaluation is large-scale with a disjoint mining/test split, parameter tuning on a separate empirical dataset, and a public replication package. The common-subset comparison in Table 6 is a transparent and useful addition. If the corrected effect sizes are reported, the paper would be a solid empirical contribution demonstrating that context-based heuristics can outperform IDE defaults and a code infilling model on this task. However, the headline quantitative claim is currently overstated, and the evidence for cross-language generalization is thin; both issues are fixable but need attention.

major comments (3)
  1. [Abstract, Section 5.6, Section 8, Tables 5 and 6] The headline claim that VarNamer improves exact-match chance by 52.6% over Eclipse and 40.7% over IntelliJ IDEA is not supported by a fair comparison. In Table 5, VarNamer's EM Precision is 41.5% (9,036/21,766), while Eclipse's 27.2% (7,380/27,158) and IDEA's 29.5% (8,022/27,158) are computed over all 27,158 cases, including the 5,392 cases where VarNamer abstains. On the common subset of 21,766 cases where VarNamer makes a recommendation, Table 6 reports Eclipse at 32.4%, IDEA at 34.5%, and Incoder at 35.1%, so the relative improvements are 28.1%, 20.3%, and 18.2%, respectively, not 52.6%, 40.7%, and 25.0%. If the intended claim is per-refactoring coverage, the improvements are even smaller (22.4% vs. Eclipse and 12.9% vs. IDEA). The abstract and conclusion repeat the inflated Table 5 numbers without noting the different denominators, even though Table 6 is reported in the body. The central comparative claim should be restated with the common-subset numbers.
  2. [Section 5.4, Section 5.6] The evaluation treats the variable name chosen by the original developer in the refactoring commit as the sole ground truth for exact-match scoring. No inter-developer or intra-developer naming consistency analysis is provided to justify this assumption. If developer-chosen names are arbitrary or inconsistent, every EM Precision and EM Coverage number measures agreement with historical choices rather than name quality. The user study in Section 5.10 partially addresses acceptability, but the automated evaluation and the comparative claims in RQ3 rest entirely on this metric assumption. A consistency study, even a small one, would make the metric considerably more credible.
  3. [Section 5.9, Section 5.2] The C++ generalization claim is based on 50 manually collected refactorings with no significance test and no confidence interval. The reported 44.0% (22/50) for VarNamer-C++ versus 12.5% (3/24) for Eclipse CDT is suggestive but not statistically supported at this sample size, and the dataset construction (10 refactorings per project, with only two instances kept per commit for multi-refactoring commits) limits representativeness. The conclusion that the approach 'can be extensively applied to other programming languages' is too strong relative to this evidence.
minor comments (5)
  1. [Section 6.2] The limitation paragraph refers to 'EMRecall', but the metric defined in Section 5.4 is EMCoverage; the terminology should be made consistent.
  2. [Section 5.9] The sentence 'the EMCoverage and EMCoverage of VarNamer-C++' repeats the same metric name; the first should presumably be EMPrecision.
  3. [Table 9] The 'Execution Time' column mixes total time and per-refactoring values in a way that is hard to read; separating total, average, and median into distinct columns would improve clarity.
  4. [Section 5.2] The statement 'we only kept two instances of them' is ambiguous; it should specify whether 'them' refers to refactorings of the same expression in a single commit or something else.
  5. [Section 2] The term 'Declaration Context' is used in Table 1 but is not defined in the terminology section; it should be introduced alongside the other context types.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: VarNamer's derivation chain is self-contained, with rules mined from disjoint corpora and evaluated on held-out refactorings.

full rationale

The paper's derivation chain does not reduce to its inputs. The empirical study (Section 3) mines context statistics from EmpiricalDataSet (4,881 refactorings from 100 projects); the generation rules are mined from MiningDataSet built from 374 projects explicitly excluding both EmpiricalDataSet and TestingDataSet (Section 4.3.1); the reuse component relies on homogeneous variables found in the code context, not on the ground-truth name; and final evaluation (Section 5.6) is conducted on TestingDataSet (27,158 refactorings) that is disjoint from both the empirical and mining data. Parameter tuning is performed on EmpiricalDataSet rather than on TestingDataSet (Section 5.5), a standard practice. The cited works (Liu et al. [61], [63]) are independent prior studies or data sources, and the only self-citations [58, 81-85] concern implementation artifacts or a standard Dice-coefficient similarity, neither of which is load-bearing. The reported 52.6% improvement is computed from different recommendation denominators (Table 5 vs. Table 6), but this is a fairness-of-comparison concern, not a circularity: the same held-out data and identical metrics are used, and the paper transparently reports the common-subset results in Table 6. No fitted parameter is renamed as a prediction, and no definitional identity makes the output equal to the input. The evaluation is self-contained against external baseline tools and a held-out dataset.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central claim rests on empirical-domain assumptions about code corpora, refactoring-detection validity, and the meaning of exact-match ground truth, plus five tunable parameters fixed on a validation set. No new theoretical entities are postulated.

free parameters (5)
  • ProjectNum = 80
    Number of projects an initialization must appear in to be considered 'universal'; tuned by grid search on EmpiricalDataSet (Section 5.5).
  • IniLength = 30
    Character-length threshold above which a homogeneous variable is trusted for reuse; tuned by grid search (Section 5.5).
  • FGSim = 0.3
    Context-similarity threshold in the fine-grained validator; tuned by grid search (Section 5.5).
  • MinConfidence = 0.8
    Minimum confidence for FP-growth association rules; empirically tuned (Section 4.3.2, 5.5).
  • MinSupport = 50
    Minimum support for FP-growth frequent itemsets; empirically tuned (Section 4.3.2, 5.5).
assumptions (5)
  • domain assumption The original developer's variable name is the correct ground truth for scoring.
    Used to define #Exact Match and all EMPrecision/EMCoverage metrics (Section 5.4).
  • domain assumption The top-1,000 starred GitHub Java projects (test) and the 374-project mining corpus are representative of typical naming practice.
    Dataset construction in Sections 3.2.1 and 4.3.1; if shifted, the mined rules lose generality.
  • domain assumption RefactoringMiner plus the authors' filters correctly identify true extract local variable refactorings.
    Section 3.2.1; false positives here would poison both empirical analysis and evaluation.
  • ad hoc to paper Searching for homogeneous variables only in the enclosing Java file retains enough useful context.
    Section 3.4.1 explicitly limits scope to the same file for efficiency; broader scopes have higher P_correct but cost more.
  • domain assumption Tokenization with spacy and javalang produces meaningful sub-token units for matching names to contexts.
    Sections 3.2.2 and 4.3.2; poor splitting would degrade both mining and evaluation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Recommending Variable Names for Extract Local Variable Refactorings." pith.science (2026). https://pith.science/paper/EOBLASEE

@misc{pith2026250700413,
  author       = {Pith},
  title        = {Pith review of: Recommending Variable Names for Extract Local Variable Refactorings},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EOBLASEE}},
  note         = {Machine review of arXiv:2507.00413}
}
read the original abstract

Extract local variable is one of the most popular refactorings, and most IDEs and refactoring tools provide automated support for this refactoring. However, we find approximately 70% of the names recommended by these IDEs are different from what developers manually constructed, adding additional renaming burdens to developers and providing limited assistance. In this paper, we introduce VarNamer, an automated approach designed to recommend variable names for extract local variable refactorings. Through a large-scale empirical study, we identify key contexts that are useful for composing variable names. Leveraging these insights, we developed a set of heuristic rules through program static analysis techniques and employ data mining techniques to recommend variable names effectively. Notably, some of our heuristic rules have been successfully integrated into Eclipse, where they are now distributed with the latest releases of the IDE. Evaluation demonstrates its superiority over state-of-the-art IDEs. Specifically, VarNamer significantly increases the chance of exact match by 52.6% compared to Eclipse and 40.7% compared to IntelliJ IDEA. We also evaluated the proposed approach with real-world extract local variable refactorings conducted in C++ projects, and the results suggest that the approach can achieve comparable performance on programming languages besides Java. It may suggest the generalizability of VarNamer. Finally, we designed and conducted a user study and the results of the user study suggest that our approach can speed up the refactoring by 27.8% and reduce 49.3% edits on the recommended variable names.

Figures

Figures reproduced from arXiv: 2507.00413 by the authors.

Figure 1
Figure 1. An Example of Extract Local Variable Refactoring [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. An Example of A False Positive version (i.e., after refactoring). An example is presented in [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Overview of VarNamer naming rules extracted from high-quality code corpora to generate potential names. Finally, a series of heuristic rules are leveraged by VarNamer to select the recommended name for developers. Detailed implementation specifics will be discussed in subsequent sections. 4.2 Reuse-Based Variable Name Recommendation Through our investigation of real-world data, we have observed that blindly reusing … view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Variable Dependency Graph variable and the homogeneous variable. If the similarity surpasses a tunable parameter 𝐹𝐺𝑆𝑖𝑚, it is considered reliable. Regarding Case4, we assess the similarity between the enclosing method of the homogeneous variable and that of the to-be-e…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

91 extracted references · 57 canonical work pages

  1. [1]

    2024. Eclipse. http://www.eclipse.org/ Manuscript submitted to ACM 34 Taiming Wang, Hui Liu, Yuxia Zhang, and Yanjie Jiang

    2024

  2. [2]

    Eclipse-CDT

    2024. Eclipse-CDT. https://projects.eclipse.org/projects/tools.cdt

    2024

  3. [3]

    Eclipse Java development tools (JDT)

    2024. Eclipse Java development tools (JDT). https://www.eclipse.org/jdt/

    2024

  4. [4]

    2024. GitHub. https://github.com

    2024

  5. [5]

    HuggingFace

    2024. HuggingFace. https://huggingface.co

    2024

  6. [6]

    IntelliJ IDEA

    2024. IntelliJ IDEA. http://www.jetbrains.com/idea/

    2024

  7. [7]

    javalang

    2024. javalang. https://github.com/c2nes/javalang

    2024

  8. [8]

    JSparrow

    2024. JSparrow. https://jsparrow.io/

    2024

Show all 91 references
  1. [9]

    NetBeans

    2024. NetBeans. http://netbeans.org/

    2024

  2. [10]

    Visual Studio

    2024. Visual Studio. https://visualstudio.com/

    2024

  3. [11]

    Loubna Ben Allal, Raymond Li, Denis Kocetkov, Chenghao Mou, Christopher Akiki, Carlos Munoz Ferrandis, Niklas Muennighoff, Mayank Mishra, Alex Gu, Manan Dey, et al. 2023. SantaCoder: don’t reach for the stars! arXiv preprint arXiv:2301.03988 (2023)

    2023 arXiv

  4. [12]

    Miltiadis Allamanis, Earl T Barr, Christian Bird, and Charles Sutton. 2014. Learning natural coding conventions. In Proceedings of the 22nd acm sigsoft international symposium on foundations of software engineering . 281–293

    2014

  5. [13]

    Barr, Christian Bird, and Charles Sutton

    Miltiadis Allamanis, Earl T. Barr, Christian Bird, and Charles Sutton. 2015. Suggesting accurate method and class names. 2015 10th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE 2...

    2015

  6. [14]

    Uri Alon, Roy Sadaka, Omer Levy, and Eran Yahav. 2020. Structural language models of code. In International conference on machine learning . PMLR, 245–256

    2020

  7. [16]

    Alsuhaibani, Christian D

    Reem S. Alsuhaibani, Christian D. Newman, Michael John Decker, Michael L. Collard, and Jonathan I. Maletic. 2022. An approach to automatically assess method names. In Proceedings of the 30th IEEE/ACM International Conference on Program Comprehension, ICPC 2022, Virtual Event, ...

    2022

  8. [17]

    Apache. 2024. Apache/arrow. Retrieved July 23, 2024 from https://github.com/apache/arrow

    2024

  9. [18]

    Apache. 2024. Apache/mesos. Retrieved July 23, 2024 from https://github.com/apache/mesos

    2024

  10. [19]

    Apache. 2024. FalsePositiveExample. Retrieved July 23, 2024 from https://github.com/apache/cassandra/commit/d292327#diff- b9a8560c03d1f86c3104c171da868f801af104fb2d76ce4b7d7eec627403309a

    2024

  11. [20]

    Apache. 2024. RefactoringExample1. Retrieved July 23, 2024 from https://github.com/apache/camel/commit/6ad3c0e#diff- 62a7cc451d91c504fd95c944a900dadce9c298a4e37a0ef2b38d09e492e379b9

    2024

  12. [21]

    Simon Butler, Michel Wermelinger, Yijun Yu, and Helen Sharp. 2009. Relating identifier naming flaws and code quality: An empirical study. In 2009 16th Working Conference on Reverse Engineering . IEEE, 31–35

    2009

  13. [22]

    Simon Butler, Michel Wermelinger, Yijun Yu, and Helen Sharp. 2010. Exploring the influence of identifier names on code quality: An empirical study. In 2010 14th European Conference on Software Maintenance and Reengineering . IEEE, 156–165

    2010

  14. [23]

    Caprile and Tonella. 2000. Restructuring program identifier names. In Proceedings 2000 International Conference on Software Maintenance . IEEE, 97–107

    2000

  15. [24]

    Shaunak Chatterjee, Sudeep Juvekar, and Koushik Sen. 2009. Sniff: A search engine for java using free-form queries. In Fundamental Approaches to Software Engineering: 12th International Conference, FASE 2009, Held as Part of the Joint European Conferences on Theory and Practic...

    2009

  16. [25]

    checkstyle. 2024. RefactoringExample4. Retrieved July 23, 2024 from https://github.com/checkstyle/checkstyle/commit/5b45d5a#diff- a16f333e36f0ee0bfdcc4164a70c6977c34dc574c37c4c7ed79718712906d30c

    2024

  17. [26]

    Qibin Chen, Jeremy Lacomis, Edward J Schwartz, Claire Le Goues, Graham Neubig, and Bogdan Vasilescu. 2022. Augmenting decompiler output with learned variable names and types. In 31st USENIX Security Symposium (USENIX Security 22) . 4327–4343

    2022

  18. [27]

    Xiangping Chen, Xing Hu, Yuan Huang, He Jiang, Weixing Ji, Yanjie Jiang, Yanyan Jiang, Bo Liu, Hui Liu, Xiaochen Li, et al. 2024. Deep Learning-based Software Engineering: Progress, Challenges, and Opportunities. arXiv preprint arXiv:2410.13110 (2024)

    2024 arXiv

  19. [28]

    Xiaye Chi, Hui Liu, Guangjie Li, Weixiao Wang, Yunni Xia, Yanjie Jiang, Yuxia Zhang, and Weixing Ji. 2023. An Automated Approach to Extracting Local Variables. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Sof...

    2023

  20. [29]

    Codota. 2024. Codota AI Autocomplete for Java and JavaScript in IntelliJ . Retrieved July 23, 2024 from https://plugins.jetbrains.com/plugin/7638- codota-ai-autocomplete-for-java-and-javascript

    2024

  21. [30]

    Jacob Cohen. 1960. A coefficient of agreement for nominal scales. Educational and psychological measurement 20, 1 (1960), 37–46

    1960

  22. [31]

    Florian Deissenboeck and Markus Pizka. 2006. Concise and consistent naming. Software Quality Journal 14, 3 (2006), 261–282. https://doi.org/10. 1007/s11219-006-9219-1

    2006

  23. [32]

    dubbo. 2024. RefactoringExample2. Retrieved July 23, 2024 from https://github.com/dubbo/dubbo/commit/2eaa132#diff- 6d63b3c410d6fad6b8661d7faa486639f7f6ac939f7f8f7732f6a33d149b036a Manuscript submitted to ACM Recommending Variable Names for Extract Local Variable Refactorings 35

    2024

  24. [33]

    Liu et al. 2024. JavaRepos. Retrieved July 23, 2024 from https://github.com/TruX-DTF/debug-method-name/tree/master/Data/JavaRepos/

    2024

  25. [34]

    Jean-Rémy Falleri, Floréal Morandat, Xavier Blanc, Matias Martinez, and Martin Monperrus. 2014. Fine-grained and accurate source code differencing. In Proceedings of the 29th ACM/IEEE international conference on Automated software engineering . 313–324

    2014

  26. [35]

    Beat Fluri, Michael Wursch, Martin PInzger, and Harald Gall. 2007. Change distilling: Tree differencing for fine-grained source code change extraction. IEEE Transactions on software engineering 33, 11 (2007), 725–743

    2007

  27. [36]

    Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Scott Yih, Luke Zettlemoyer, and Mike Lewis. 2023. InCoder: A Generative Model for Code Infilling and Synthesis. In The Eleventh International Conference on Learning Representations, IC...

    2023

  28. [37]

    geoserver. 2024. RefactoringExample3. Retrieved July 23, 2024 from https://github.com/geoserver/geoserver/commit/c54d9cc#diff- 40dd1af56b59d542f9c41036b47c0db77b2b4a5bc8ece7a2f4a78cc196867181

    2024

  29. [38]

    Yaroslav Golubev, Zarina Kurbatova, Eman Abdullah AlOmar, Timofey Bryksin, and Mohamed Wiem Mkaouer. 2021. One thousand and one stories: a large-scale survey of software refactoring. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and S...

    2021

  30. [39]

    Google. 2024. Google/angle. Retrieved July 23, 2024 from https://github.com/google/angle

    2024

  31. [40]

    Google. 2024. Google/dawn. Retrieved July 23, 2024 from https://github.com/google/dawn

    2024

  32. [41]

    Google. 2024. Google/skia. Retrieved July 23, 2024 from https://github.com/google/skia

    2024

  33. [42]

    Daya Guo, Shuai Lu, Nan Duan, Yanlin Wang, Ming Zhou, and Jian Yin. 2022. Unixcoder: Unified cross-modal pre-training for code representation. arXiv preprint arXiv:2203.03850 (2022)

    2022 arXiv

  34. [43]

    Tihomir Gvero, Viktor Kuncak, Ivan Kuraj, and Ruzica Piskac. 2013. Complete completion using types and weights. In ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI ’13, Seattle, W A, USA, June 16-19, 2013 , Hans-Juergen Boehm and Cormac Flanagan (...

    2013

  35. [44]

    Jiawei Han and Jian Pei. 2000. Mining frequent patterns by pattern-growth. ACM SIGKDD Explorations Newsletter 2, 2 (2000), 14–20. https: //doi.org/10.1145/380995.381002

    2000

  36. [45]

    Vincent J Hellendoorn and Premkumar Devanbu. 2017. Are deep neural networks the best choice for modeling source code?. In Proceedings of the 2017 11th Joint meeting on foundations of software engineering . 763–773

    2017

  37. [46]

    Matthew Honnibal and Ines Montani. 2024. spaCy. https://spacy.io/

    2024

  38. [47]

    Einar W Høst and Bjarte M Østvold. 2009. Debugging method names. In European Conference on Object-Oriented Programming . Springer, 294–317

    2009

  39. [48]

    JetBrains. 2024. Extract/Introduce variable. Retrieved July 23, 2024 from https://www.jetbrains.com/help/idea/extract-variable.html

    2024

  40. [49]

    Seohyun Kim, Jinman Zhao, Yuchi Tian, and Satish Chandra. 2021. Code prediction by feeding trees to transformers. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) . IEEE, 150–162

    2021

  41. [50]

    Sotiris Kotsiantis and Dimitris Kanellopoulos. 2006. Association Rules Mining: A Recent Overview. Science 32, 1 (2006), 71–82

    2006

  42. [51]

    Jeremy Lacomis, Pengcheng Yin, Edward Schwartz, Miltiadis Allamanis, Claire Le Goues, Graham Neubig, and Bogdan Vasilescu. 2019. Dire: A neural approach to decompiled identifier naming. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IE...

    2019

  43. [52]

    Dawn Lawrie, Henry Feild, and David Binkley. 2007. Quantifying identifier quality: an analysis of trends. Empirical Software Engineering 12 (2007), 359–388

    2007

  44. [53]

    Dawn Lawrie, Christopher Morrell, Henry Feild, and David Binkley. 2006. What’s in a name? A study of identifiers. IEEE International Conference on Program Comprehension 2006 (2006), 3–12. https://doi.org/10.1109/ICPC.2006.51

    2006 doi

  45. [54]

    Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, Qian Liu, Evgenii Zheltonozhskii, Terry Yue Zhuo, Thomas Wang, Olivier Dehaene, Mishig Davaadorj, Joel Lamy-Poirier, João Monteiro, ...

    2023 arXiv

  46. [55]

    Yi Li, Shaohua Wang, and Tien N. Nguyen. 2021. A Context-based Automated Approach for Method Name Consistency Checking and Suggestion. In 43rd IEEE/ACM International Conference on Software Engineering, ICSE 2021, Madrid, Spain, 22-30 May 2021 . IEEE, 574–586. https://doi.org/1...

    2021

  47. [56]

    B. Lin, C. Nagy, G. Bavota, A. Marcus, and M. Lanza. 2019. On the Quality of Identifiers in Test Code. In 2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM) . 204–215. https://doi.org/10.1109/SCAM.2019.00031

    2019

  48. [57]

    B. Lin, S. Scalabrino, A. Mocci, R. Oliveto, G. Bavota, and M. Lanza. 2017. Investigating the Use of Code Analysis and NLP to Promote a Consistent Usage of Identifiers. In 2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM) . 81–90. ...

    2017 doi

  49. [58]

    Bo Liu, Hui Liu, Nan Niu, Yuxia Zhang, Guangjie Li, and Yanjie Jiang. 2023. Automated Software Entity Matching Between Successive Versions. In Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE ’23) . IEEE, 1615–1627. https://doi.o...

    2023

  50. [59]

    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 . 1294–1306

    2022

  51. [60]

    Fang Liu, Ge Li, Yunfei Zhao, and Zhi Jin. 2020. Multi-task learning based pre-trained language model for code completion. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering . 473–485

    2020

  52. [61]

    Hui Liu, Qiurong Liu, Cristian-Alexandru Staicu, Michael Pradel, and Yue Luo. 2016. Nomen est Omen: Exploring and Exploiting Similarities between Argument and Parameter Names. In 2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE) . 1063–1073. https: //d...

    2016

  53. [62]

    Hao Liu, Yanlin Wang, Zhao Wei, Yong Xu, Juhong Wang, Hui Li, and Rongrong Ji. 2023. RefBERT: A Two-Stage Pre-trained Framework for Automatic Rename Refactoring. (2023). https://doi.org/10.1145/3597926.3598092 arXiv:2305.17708

    2023

  54. [63]

    Bissyande, Taeyoung Kim, Kisub Kim, Anil Koyuncu, Suntae Kim, and Yves Le Traon

    Kui Liu, Dongsun Kim, Tegawende F. Bissyande, Taeyoung Kim, Kisub Kim, Anil Koyuncu, Suntae Kim, and Yves Le Traon. 2019. Learning to Spot and Refactor Inconsistent Method Names. Proceedings - International Conference on Software Engineering 2019-May (2019), 1–12. https: //doi...

    2019

  55. [64]

    Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo Geng, Wenxiang Hu, Chongyang Tao, Jing Ma, Qingwei Lin, and Daxin Jiang. 2023. Wizardcoder: Empowering code large language models with evol-instruct. arXiv preprint arXiv:2306.08568 (2023)

    2023 arXiv

  56. [65]

    David Mandelin, Lin Xu, Rastislav Bodík, and Doug Kimelman. 2005. Jungloid mining: helping to navigate the API jungle. ACM Sigplan Notices 40, 6 (2005), 48–61

    2005

  57. [66]

    Antonio Mastropaolo, Emad Aghajani, Luca Pascarella, and Gabriele Bavota. 2023. Automated variable renaming: are we there yet? Empirical Software Engineering 28, 2 (2023), 1–26. https://doi.org/10.1007/s10664-022-10274-8 arXiv:2212.05738

    2023 arXiv

  58. [67]

    Niklas Muennighoff, Qian Liu, Armel Zebaze, Qinkai Zheng, Binyuan Hui, Terry Yue Zhuo, Swayam Singh, Xiangru Tang, Leandro Von Werra, and Shayne Longpre. 2023. Octopack: Instruction tuning code large language models. arXiv preprint arXiv:2308.07124 (2023)

    2023 arXiv

  59. [68]

    Murphy-Hill, Chris Parnin, and Andrew P

    Emerson R. Murphy-Hill, Chris Parnin, and Andrew P. Black. 2012. How We Refactor, and How We Know It. IEEE Trans. Software Eng. 38, 1 (2012), 5–18. https://doi.org/10.1109/TSE.2011.41

    2012 doi

  60. [69]

    Johnson, and Danny Dig

    Stas Negara, Nicholas Chen, Mohsen Vakilian, Ralph E. Johnson, and Danny Dig. 2013. A comparative study of manual and automated refactorings. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 79...

    2013 doi

  61. [70]

    Son Nguyen, Hung Phan, Trinh Le, and Tien N. Nguyen. 2020. Suggesting natural method names to check name consistencies. In ICSE ’20: 42nd International Conference on Software Engineering, Seoul, South Korea, 27 June - 19 July, 2020. ACM, 1372–1384. https://doi.org/10.1145/3377...

    2020

  62. [71]

    Vikram Nitin, Anthony Saieva, Baishakhi Ray, and Gail Kaiser. 2021. DIRECT: A Transformer-based Model for Decompiled Variable Name Recovery. NLP4Prog 2021 (2021), 48

    2021

  63. [72]

    Anthony Peruma, Venera Arnaoudova, and Christian D. Newman. 2021. IDEAL: An Open-Source Identifier Name Appraisal Tool. (2021). arXiv:2107.08344 http://arxiv.org/abs/2107.08344

    2021 arXiv

  64. [73]

    Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. 2020. Exploring the limits of transfer learning with a unified text-to-text transformer. Journal of Machine Learning Research 21 (2020), 1–67. arXiv:1910.10683

    2020 arXiv

  65. [74]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al

  66. [75]

    Alexey Svyatkovskiy, Sebastian Lee, Anna Hadjitofi, Maik Riechert, Juliana Vicente Franco, and Miltiadis Allamanis. 2021. Fast and memory-efficient neural code completion. In 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR) . IEEE, 329–340

    2021

  67. [76]

    Andreas Thies and Christian Roth. 2010. Recommending rename refactorings. Proceedings - International Conference on Software Engineering (2010), 1–5. https://doi.org/10.1145/1808920.1808921

    2010

  68. [77]

    Nikolaos Tsantalis, Ameya Ketkar, and Danny Dig. 2022. RefactoringMiner 2.0. IEEE Trans. Software Eng. 48, 3 (2022), 930–950. https://doi.org/10. 1109/TSE.2020.3007722

    2022

  69. [78]

    Nikolaos Tsantalis, Matin Mansouri, Laleh Mousavi Eshkevari, Davood Mazinanian, and Danny Dig. 2018. Accurate and efficient refactoring detection in commit history. In Proceedings of the 40th International Conference on Software Engineering, ICSE 2018, Gothenburg, Sweden, May ...

    2018

  70. [79]

    Zhaopeng Tu, Zhendong Su, and Premkumar T. Devanbu. 2014. On the localness of software. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, (FSE-22), Hong Kong, China, November 16 - 22, 2014 , Shing-Chi Cheung, Alessandro Orso...

    2014

  71. [80]

    Shangwen Wang, Ming Wen, Bo Lin, and Xiaoguang Mao. 2021. Lightweight global and local contexts guided method name recommendation with prior knowledge. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of ...

    2021

  72. [81]

    Taiming Wang. 2024. Automated Name Recommendation For The Extract Local Variable Refactoring . Retrieved July 23, 2024 from https://github.com/ eclipse-jdt/eclipse.jdt.ui/pull/602

    2024

  73. [82]

    Taiming Wang. 2024. Context-based-name-recommendation. Retrieved July 23, 2024 from https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/656 Manuscript submitted to ACM Recommending Variable Names for Extract Local Variable Refactorings 37

    2024

  74. [83]

    Taiming Wang. 2024. Extract Similar Expression in All Methods If End-Users Want . Retrieved July 23, 2024 from https://github.com/eclipse- jdt/eclipse.jdt.ui/pull/680

    2024

  75. [84]

    Taiming Wang. 2024. Recommend variable name for Extracted Local Variable Refactoring when the extracted expression is a method invocation . Retrieved July 23, 2024 from https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/685

    2024

  76. [85]

    Taiming Wang. 2024. VarNamer. Retrieved July 23, 2024 from https://github.com/Michaelll123/VarNamer

    2024

  77. [86]

    Taiming Wang, Yuxia Zhang, Lin Jiang, Yi Tang, Guangjie Li, and Hui Liu. 2025. Deep learning based identification of inconsistent method names: How far are we? Empirical Software Engineering 30, 1 (2025), 31

    2025

  78. [87]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven CH Hoi. 2021. Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation. arXiv preprint arXiv:2109.00859 (2021)

    2021 arXiv

  79. [88]

    Li Yujian and Liu Bo. 2007. A normalized Levenshtein distance metric. IEEE transactions on pattern analysis and machine intelligence 29, 6 (2007), 1091–1095

    2007

  80. [89]

    Jingxuan Zhang, Junpeng Luo, Jiahui Liang, Lina Gong, and Zhiqiu Huang. 2023. An Accurate Identifier Renaming Prediction and Suggestion Approach. ACM Transactions on Software Engineering and Methodology (2023). https://doi.org/10.1145/3603109

    2023 doi

  81. [90]

    Jie Zhu, Lingwei Li, Li Yang, Xiaoxiao Ma, and Chun Zuo. 2023. Automating Method Naming with Context-Aware Prompt-Tuning. arXiv preprint arXiv:2303.05771 (2023)

    2023 arXiv

  82. [91]

    Daniel Zügner, Tobias Kirschstein, Michele Catasta, Jure Leskovec, and Stephan Günnemann. 2021. Language-agnostic representation learning of source code from structure and context. arXiv preprint arXiv:2103.11318 (2021). Manuscript submitted to ACM

    2021 arXiv

  83. [2023]

    arXiv preprint arXiv:2308.12950 (2023)

    Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950 (2023)

    2023 arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.