Pith. Sign in

RECORD

Improving Semantic Consistency of Variable Names with Use-Flow Graph Analysis

PaperPDF from arXiv

data files

Paper breakdownThe authors' claims, conditions and measurements, as JSON Signed receiptProof this review has not been altered
X Bluesky LinkedIn Reddit Hacker News
Yusuke Shinyama, Yoshitaka Arahori, Katsuhiko Gondow

Software Engineering · Submitted 18 Mar 2022

abstract compiled · 2026-09-23 · no language-model review

The authors' main claim Our system proposed alternative variable names for 416 out of 1080 (39%) instances that are considered better than ones originally used by the developers.

how it is stated · asserted 1.00 read the record →

Comment (0) Read on arXiv ↗
Cite ▾
arXiv ID2203.09960 (version 1)
Pith IDWTOJCZXD, Pith's permanent record of this paper and its review
CitationKatsuhiko Gondow, Yoshitaka Arahori, Yusuke Shinyama. "Improving Semantic Consistency of Variable Names with Use-Flow Graph Analysis." arXiv:2203.09960 (2022). https://pith.science/paper/WTOJCZXD
Claim paper

The compiled record

The paper's own sentences, arranged. Each label is drawn from a closed vocabulary; the number beside it is the probability the classifier gave that label. Numbers in the tables are the authors', checked by code. No sentence in this record was written by a model.

Open the compiled record

Compiled by classifier-1.13.0 via TypeSafe API, question bank abstract-p1-20260923, 2026-09-23: 1 request, 6,682 input tokens.

What the abstract itself states, as probabilities: claims first 0.14 · states limitation 0.24 · human participants 0.85 · controlled comparison 0.18 · randomized assignment 0.01 · states quantitative result 0.99 · compares with prior results 0.14 · mentions code or data availability 0.05.

The abstract, sentence by sentence

arXiv listing abstract v1. Results and the main claim are underlined; .

Consistency is one of the keys to maintainable source code and hence a successful software project. We propose a novel method of extracting the intent of programmers from source code of a large project (~300kLOC) and checking the semantic consistency of its variable names. Our system learns a project-specific naming convention for variables based on its role solely from source code, and suggest alternatives when it violates its internal consistency. The system can also show the reasoning why a certain variable should be named in a specific way. The system does not rely on any external knowledge. We applied our method to 12 open-source projects and evaluated its results with human reviewers. Our system proposed alternative variable names for 416 out of 1080 (39%) instances that are considered better than ones originally used by the developers. Based on the results, we created patches to correct the inconsistent names and sent them to its developers. Three open-source projects adopted it.

background contribution method result interpretation main claim

What the classifier reports for each sentence. The number is the probability it gave the label.
#sentencerolethe authors' own workstates the main conclusionstrength
s0 Consistency is one of the keys to maintainable source code and hence a successful software project. background 1.00 0.04 0.03 asserted 1.00
s1 We propose a novel method of extracting the intent of programmers from source code of a large project (~300kLOC) and checking the semantic consistency of its variable names. contribution 0.99 0.93 0.09 asserted 0.99
s2 Our system learns a project-specific naming convention for variables based on its role solely from source code, and suggest alternatives when it violates its internal consistency. method 0.91 0.89 0.10 asserted 0.99
s3 The system can also show the reasoning why a certain variable should be named in a specific way. contribution 0.56 0.82 0.05 asserted 0.90
s4 The system does not rely on any external knowledge. method 0.74 0.56 0.03 asserted 1.00
s5 We applied our method to 12 open-source projects and evaluated its results with human reviewers. method 0.92 0.97 0.04 asserted 1.00
s6 Our system proposed alternative variable names for 416 out of 1080 (39%) instances that are considered better than ones originally used by the developers. result 1.00 0.97 0.42 asserted 1.00
s7 Based on the results, we created patches to correct the inconsistent names and sent them to its developers. contribution 0.42 0.95 0.09 asserted 1.00
s8 Three open-source projects adopted it. result 0.98 0.86 0.15 asserted 1.00

What kind of paper the classifier reports this is: method or tool 1.00 · evidence from observation or experiment 0.99.

What was examined, and what was not

sources read
  • arXiv listing abstract v1
not examined
  • full text
  • figures and tables
  • references and citing sentences
  • relations to other papers
levels run
  • P abstract
not run
  • S sections
  • T body sentences
  • C citations
  • R cross-paper relations

Every quoted sentence on this record is the authors'. Every label is from Pith's closed vocabulary, with the probability shown beside it. Every number in the measurements table is the authors', checked by code. Record as JSON

The paper
Original abstract

Consistency is one of the keys to maintainable source code and hence a successful software project. We propose a novel method of extracting the intent of programmers from source code of a large project (~300kLOC) and checking the semantic consistency of its variable names. Our system learns a project-specific naming convention for variables based on its role solely from source code, and suggest alternatives when it violates its internal consistency. The system can also show the reasoning why a certain variable should be named in a specific way. The system does not rely on any external knowledge. We applied our method to 12 open-source projects and evaluated its results with human reviewers. Our system proposed alternative variable names for 416 out of 1080 (39%) instances that are considered better than ones originally used by the developers. Based on the results, we created patches to correct the inconsistent names and sent them to its developers. Three open-source projects adopted it.

Human review

How Pith checks papers → · Full audit of this paper →

How the literature uses it

What this paper does with the arXiv papers it cites

Each citing sentence is taken from the citing paper's LaTeX source and typed by Pith's classifier. A label appears at probability 0.8 or more (0.95 for support), a contest at 0.7 or more; the quoted words are the citing authors'. How each label was checked · JSON

Discussion

Know something about this paper? Leave a comment, or highlight any passage above to comment on it.