codehelion は Rust / C / C++ のコードベースから重複ロジックを検出し、スキャンをまたいで同じ重複を追い続けるツールです。
読むのはソースそのものです。先にビルドを走らせる必要も、compile_commands.json を用意する必要もなく、ツールのどこにもネットワークアクセスはありません。完全一致・リネーム・欠落を伴うコピーを検出し、単一のスコアではなく複数の指標を並べて報告し、各 finding には無関係な編集では変わらない内容由来の識別子を付けます。一度判断した重複は判断済みのまま残り、数か月後のスキャンを前回のスキャンと突き合わせられます。
codehelion は 1.0 前です。コマンドラインの形・レポート形式・データベースのレイアウトはリリース間で変わり得ます。
スキャンは対応するソースファイルをエラー耐性のある lexer で読みます。構文として壊れているファイルでも、読める部分は結果に寄与します。比較の前にコメントと空白を除き、識別子とリテラルは設定した戦略に従って正規化します。
そこから得られたものを内容で索引します。本体全体を unit として、その中の文の連なりを fragment として扱います。候補ペアはこの索引から作られ、fingerprint が一致すれば完全一致の種、shingle の重なりが十分なら近似一致の提案となります。各候補はアラインメントで検証されてから finding になります。検証を通ったペアは canonical member を基準にグループ化されます。canonical member とは、そのグループの他のすべての出現箇所が比較対象にした 1 件です。
実行結果はローカルの SQLite に記録され、text・JSON・SARIF のレポートはその記録からのエクスポートです。レポートを描き直すときにツリーを読み直すことはありません。
各段階にはリソース上限があり、発火した上限はすべてレポートに計上されます。候補 budget が探索を打ち切るほど大きなツリーでは、未検査のまま残したペア数を明示し、部分的な答えを完全な答えとして提示しません。
重複は一度で出そろうものではありません。ある修正を二か所目に写したとき、同じ問題を同じ週に二人が別々に解いたとき、そして既存の実装を探しに行く理由のないコードが生成されたときに、その都度また増えます。厄介なのは重複が存在すること自体ではなく、見失われることです。誰も判断を覚えていないコピーは毎回のスキャンで報告され直し、残すと決めたはずのコピーはまた議論の対象になります。
それを止めるのが安定した識別子と baseline です。finding は内容によって名前を持つため、その finding に記録した判断は周辺の編集を越えて残ります。安定した識別子と baseline を参照してください。
finding が名指しするのは、読み手が同期を取り続ける必要のあるコードです。これは保守性の指標であってサイズの指標ではありません。最適化器はソース上で重複したままのコードを日常的に畳むため、報告されたクローンを解消しても成果物が小さくなるとは限りません。そちらは成果物解析が別に測ります。両者の隔たりがどれほど大きいかは制限に書いてあります。
各グループは、その出現箇所どうしが何を共有しているかを報告します。lexical / structural / control-flow / type / API の類似度と、そこから導かれる clone confidence・maintenance risk・refactoring difficulty です。実行中のモードで測れない次元は、推測せず「測定なし」として報告します。そのグループをどうするかの判断は読み手に委ねます。
汎用のコード品質プラットフォーム、脆弱性スキャナ、コーディング規約チェッカ、リファクタリングツールのいずれでもありません。意味的等価性を証明せず、サイズ削減を保証せず、自動でリファクタリングもしません。ミラー整合性検査ツールでもありません。見つけた重複を報告するだけで、すべてのコピーを見つけたとは主張しません。