自動修正されたコードは、読みやすさを保てているか Does auto-repaired code still read cleanly?
テストに通るパッチは「正しい」。でも、機械が書いたその修正は、規約や可読性まで守れているのか。 A patch that passes the tests is "correct." But does a machine-written fix also respect coding standards and readability?
規約の種類によらず、APRパッチの約4〜6割が規約違反を増加（Math でも43〜47%）。増えた違反のうち LeftCurly・NeedBraces がそれぞれ約9〜10%で可読性に影響。 Regardless of the standard, about 40-60% of APR patches add violations (43-47% for Math). Among added violations, LeftCurly and NeedBraces each account for ~9-10% and affect readability.
自動プログラム修正（APR: Automated Program Repair）は、不具合修正の負担を減らす技術として研究が進んでいます。しかしその品質評価は、テストに通るか（正しさ）に偏っており、生成されたパッチがコーディング規約や可読性をどれだけ損なうかはほとんど検討されてきませんでした。本研究は、Defects4J の3つのOSSプロジェクト（Lang・Math・Time）に対し 32 のAPRツールが生成したパッチを適用し、Checkstyle を用いてプロジェクト独自規約・Google Java Style・Sun Code Conventions の3規約に照らした違反の増減を定量的に分析しました。 Automated Program Repair (APR) is a growing approach to reduce the burden of fixing defects. Yet patch quality has been judged mainly by test-passing (correctness), and little attention has been paid to how much generated patches harm coding standards and readability. This study applies patches from 32 APR tools to three OSS projects from Defects4J (Lang, Math, Time) and uses Checkstyle to quantify how violations change against three standards: the project's own rules, Google Java Style, and Sun Code Conventions.
3つのポイントThree takeaways
RQ1パッチの4〜6割が違反を増やす40-60% of patches add violations
APRが生成したパッチのうち、規約の種類によらず約4〜6割がコーディング規約違反を増やしていました。正しさは満たしても、コードの整い方は犠牲になりがちです。Regardless of the standard, about 40-60% of APR patches increased coding-standard violations. Correctness is met, but tidiness suffers.
RQ2多くは軽微、一部は可読性に影響Mostly minor, some hurt readability
増えた違反の多くは軽微でしたが、波括弧の位置（LeftCurly）や省略（NeedBraces）のように可読性に影響する違反もそれぞれ約9〜10%を占めました。見過ごせない割合が残ります。Most added violations were minor, but readability-affecting types such as brace placement (LeftCurly) and omitted braces (NeedBraces) each account for about 9-10%, a non-negligible share.
RQ3生成方式が似ると違反も似るSimilar tools, similar violations
似た方式でパッチを生成するAPRツールは、似た傾向の規約違反を生みました。違反の癖は、ツールの生成メカニズムに根ざしています。APR tools that generate patches in similar ways produced similar violations. The tendencies are rooted in how each tool synthesizes code.
研究の進め方The study in four steps
対象の特定Locate
開発者パッチが適用されたファイルを検索し、修正対象を洗い出す。Find the files a developer patch touched to identify repair targets.
修正前の復元Pre-fix version
適用前のファイルを特定し、APR適用の起点をそろえる。Recover the pre-patch file so every APR run starts from the same point.
APR適用Apply APR
32のAPRツールでパッチを生成・適用する。Generate and apply patches with 32 APR tools.
違反の計測Measure
Checkstyleで独自・Google・Sun の3規約の違反を計測し、増減を比較。Run Checkstyle for the project, Google and Sun standards and compare the change.
なぜ重要かWhy it matters
APR研究の評価は「テストを通す正しさ」に偏りがちですが、実際に開発現場へ導入するには、保守性や可読性を損なわないことも欠かせません。本研究は、正しさの陰に隠れていた「規約違反」というコストを可視化し、APRツールの生成方式を設計・選定する際の具体的な指針を与えます。 APR is usually judged on test-passing correctness, but real adoption also requires not degrading maintainability and readability. By surfacing the hidden cost of standard violations, this work offers concrete guidance for designing and choosing APR tools.
分析の要点Method notes
- 対象：Defects4J の Lang・Math・Time。
Checkstyleでプロジェクト独自規約・Google Java Style・Sun Code Conventions を検査。Targets: Lang, Math, Time from Defects4J;Checkstyleagainst the project's own rules, Google Java Style and Sun Code Conventions. - 比較：各ツールの違反傾向をコサイン距離で比較し、生成方式との関係を分析。Comparison: violation tendencies across tools compared by cosine distance to relate them to generation strategy.
- 視点：「正しさ」だけでなく「整い方」からAPRを評価。Lens: evaluating APR by tidiness, not correctness alone.
背景・手法・全結果を詳しくBackground, method, and full results
データセット、各RQの詳しい数値、妥当性の脅威までを解説した詳細ページがあります。A detailed page covers the dataset, the numbers behind each RQ, and threats to validity.