研究の詳細The study in depth
背景と位置づけから、データセット、RQ1〜RQ3の結果、考察、妥当性の脅威までを順に解説します。要点だけを見たい場合は概要ページへ。 Background and positioning, dataset, the RQ1-RQ3 results, discussion, and threats to validity, in order. For the short version, see the overview.
背景と位置づけBackground and positioning
自動プログラム修正（APR）は、不具合修正の負担を減らす技術として活発に研究されています。しかしその品質評価は、テストに通るか（正しさ／correctness）に大きく偏ってきました。生成されたパッチが、その後の保守を担う人にとって読みやすいか、プロジェクトのコーディング規約に沿っているかは、ほとんど検討されていません。 Automated Program Repair (APR) is actively studied as a way to reduce the burden of fixing defects. Yet its quality has been judged mainly by whether tests pass (correctness). Whether the generated patch is readable for whoever maintains it next, or whether it follows the project's coding standards, has been largely overlooked.
本研究は、コーディング規約への適合を可読性・一貫性の代理指標とみなし、静的解析ツール Checkstyle を用いて、APRパッチが規約違反をどれだけ増やすかを定量化します。正しさ一辺倒だったAPR評価に、「整い方」という軸を加える位置づけです。
Treating conformance to coding standards as a proxy for readability and consistency, this study uses the static analyzer Checkstyle to quantify how much APR patches increase standard violations. It adds a "tidiness" axis to an APR evaluation culture centered on correctness alone.
手法Method
データセットDataset
Defects4J の3プロジェクト（Lang・Math・Time）を対象に、32のAPRツールが生成したパッチを用います。各不具合について修正前のファイルを復元し、APRパッチを適用したうえで Checkstyle を実行。プロジェクト独自規約・Google Java Style・Sun Code Conventions の3種の規約に対する違反数を、適用前後で比較します。
We target three Defects4J projects (Lang, Math, Time) and patches from 32 APR tools. For each bug we recover the pre-fix file, apply the APR patch, and run Checkstyle, comparing violation counts before and after against three standards: the project's own rules, Google Java Style, and Sun Code Conventions.
再現の確からしさReproduction reliability
対象不具合のうち再現できたのは Lang が13件中11件（84.6%）、Math が51件中30件（58.8%）。Time は再現数が限られます。APRツールが生成したパッチ数は Lang・Math で数百〜千件規模にのぼります。 Of the target bugs, 11 of 13 reproduced for Lang (84.6%) and 30 of 51 for Math (58.8%); Time is limited. The APR tools produced hundreds to over a thousand patches for Lang and Math.
CheckstyleRQ1: APRは規約違反を増やすかRQ1: Do patches add violations?
APRパッチのうち、コーディング規約違反を増加させたものの割合を規約別・プロジェクト別に示します。多くの条件で約40%以上のパッチが違反を増やしており、規約の種類によらずこの傾向が見られました。Time は再現数が少なく、割合の解釈には注意が要ります。 The share of APR patches that increased coding-standard violations, by standard and project. In most conditions about 40% or more of patches added violations, regardless of the standard. Time has few reproductions, so its ratios should be read with care.
| プロジェクトProject | 独自規約Project | Sun | |
|---|---|---|---|
| Lang | 49.2% | 60.7% | 56.6% |
| Math | 47.3% | 43.2% | 43.6% |
| Time | 20.0% | 40.0% | 40.0% |
各セルは「違反を増やしたAPRパッチ」の割合。規約の種類を問わず高い水準にある。Each cell is the share of APR patches that increased violations, high across all standards.
RQ2: 増えた違反はどれだけ深刻かRQ2: How serious are the added violations?
増加した違反の種類を上位から見ると、その多くは空白やタブ、インデントに関する軽微なもの（WhitespaceAround・WhitespaceAfter・FileTabCharacter・Indentation）でした。一方で、波括弧の位置（LeftCurly）や中括弧の省略（NeedBraces）のように可読性に直接影響する違反も約9〜10%を占めます。整形で直せるものが大半とはいえ、見過ごせない割合が残ります。
The most frequent added violations are minor ones about whitespace, tabs, and indentation (WhitespaceAround, WhitespaceAfter, FileTabCharacter, Indentation). But violations that directly affect readability, such as brace placement (LeftCurly) and omitted braces (NeedBraces), make up about 9-10%. Most are auto-formattable, yet a non-negligible share is not.
| 違反の種類（上位）Top violation types | Sun | |
|---|---|---|
| WhitespaceAround | 50.0% | 50.9% |
| WhitespaceAfter | 47.1% | 48.0% |
| FileTabCharacter | 40.2% | 41.5% |
| Indentation | 55.2% | - |
| LineLength | 10.9% | 22.2% |
| 可読性に影響する違反Readability-affecting | ||
| LeftCurly | 9.8% | 10.5% |
| NeedBraces | 9.2% | 9.4% |
増加した違反に占める各種別の割合（Google／Sun）。上位は空白・タブ系だが、下段の可読性に関わる違反も一定割合ある。Share of each type among added violations (Google/Sun). Whitespace/tab types dominate, but readability-related types persist.
RQ3: ツールの類似性と違反の類似性RQ3: Similar tools, similar violations
各APRツールが生む違反の種類をベクトル化し、コサイン距離で類似度を測って階層クラスタリングしました。すると、似た方式でパッチを生成するツールどうしが同じクラスタに集まる傾向が、Google・Sun の両規約で確認できました（例：テンプレート／パターンに基づく修正を行うツール群）。違反の「癖」は、ツールの生成メカニズムに根ざしていると考えられます。 We vectorized the violation types each APR tool produces and clustered them hierarchically by cosine distance. Tools that generate patches in similar ways cluster together, under both Google and Sun standards (e.g., template- or pattern-based repair tools). The tendencies in violations appear rooted in how each tool synthesizes code.
考察Discussion
- 正しさの先へ：APRを実務に導入するには、テスト通過だけでなく、生成コードの保守性・可読性の評価が欠かせない。Beyond correctness: adopting APR in practice requires evaluating the maintainability and readability of generated code, not just test-passing.
- 設計指針：違反傾向は生成方式に結びつくため、ツール選定・設計の判断材料になる。Design guidance: because violation tendencies tie to generation strategy, they can inform tool selection and design.
- 後処理の余地：増加分の多くは整形で解消可能。APR出力に自動整形を組み合わせる価値がある。Room for post-processing: much of the increase is fixable by formatting, so pairing APR output with auto-formatting is worthwhile.
妥当性の脅威Threats to validity
構成概念：コーディング規約違反は可読性の代理指標であり、可読性そのものではありません。規約の設定（Checkstyle構成）を変えれば結果も変わり得ます。Construct: standard violations are a proxy for readability, not readability itself; results may shift with a different Checkstyle configuration.
外的妥当性：対象は Defects4J の Lang・Math・Time、言語はJava、APRツールは特定のデータセット由来の32種です。他プロジェクト・他言語・他ツールへの一般化には注意が必要です。External: targets are Lang, Math, and Time from Defects4J, in Java, with 32 tools from a specific dataset, so generalization to other projects, languages, or tools warrants care.