Ghost Methods Explained
Ghost methods are function or method calls that appear in a codebase's source code but have no corresponding definition anywhere in the analyzed repository. They are symbols that are called but never defined — the code references them, but the implementation either does not exist, exists in an unanalyzed dependency, or was deleted without removing all call sites.
Why It Matters
Ghost methods indicate one of three conditions, each carrying different implications:
Missing implementations — the function was planned but never written, or was deleted without removing call sites. This is a latent runtime error waiting to surface.
External dependencies — the function is defined in a third-party library or framework that was not included in the analysis scope. This is not a bug but indicates an external dependency that should be documented.
Dynamic resolution — the function is defined dynamically at runtime through metaprogramming, reflection, or code generation. This is a legitimate pattern but one that creates architectural relationships invisible to static analysis.
Regardless of the cause, ghost methods represent gaps in the architectural record. Each ghost method is a dependency that the analysis cannot fully resolve, reducing confidence in the completeness of the dependency graph.
How It Works
Ghost method detection works by comparing the set of all function calls in the codebase against the set of all function definitions.
Call site extraction parses every file and identifies all function/method invocations — direct calls, method calls on objects, constructor invocations, and higher-order function references.
Definition extraction parses every file and identifies all function/method/class definitions — named functions, class methods, constructors, and exported symbols.
The difference between the two sets — calls that have no matching definition — produces the ghost method list. Each ghost method is annotated with its call site count (how many places call it), the files that call it, and a likely source classification (missing implementation, external dependency, or dynamic resolution).
Filtering removes known standard library functions, framework-provided methods, and built-in language constructs to reduce false positives.
How Axiom Refract Addresses This
- Axiom Refract detects ghost methods via the get_ghost_methods tool — returning symbol names, call site counts, and likely source classifications
- Ghost method findings are included in the migration plan as action items to investigate and resolve
- The analysis distinguishes between ghost methods likely from external dependencies and those likely from missing implementations