[Paper] Supporting the Comprehension of Data Analysis Scripts

Source: arXiv - 2604.15963v1

Overview

The paper introduces flowR, a lightweight extension for the popular R IDEs (Positron and VS Code) that gives data analysts a live, visual overview of their analysis scripts. By automatically building a data‑flow graph and adding linting, inline value hints, and interactive visualizations, flowR tackles the chronic problem of hard‑to‑understand R scripts that hampers reproducibility and collaborative work.

Key Contributions

• Incremental interprocedural data‑ and control‑flow analysis for R projects, handling the language’s dynamic features.
• Real‑time data‑flow graph generation (average 576 ms for real‑world codebases), enabling near‑instant feedback.
• IDE integration (Positron & VS Code) with interactive graph visualizations, linting, and inline value annotations.
• Extensible plugin architecture that lets developers add custom lint rules or bespoke visualizations.
• Open‑source release (GitHub repo, Docker image) with comprehensive documentation and a demo video.

Methodology

1. Static Backward Program Slicer – The authors build on a previously published slicer that works backwards from a variable of interest to identify all statements that could affect its value.
2. Interprocedural Analysis – flowR walks through function calls, imports, and R’s lazy evaluation semantics to stitch together a global data‑flow graph across the whole project.
3. Incremental Updates – Instead of recomputing the entire graph on every edit, flowR only re‑analyzes the changed parts, keeping the turnaround time under a second.
4. IDE Hooking – The analysis engine is exposed via a language‑server‑protocol (LSP) extension, so the IDE can request the graph, lint results, or inline values on demand.
5. Plugin System – A well‑defined API lets third‑party modules register new analyses, which the IDE can render as additional panels or diagnostics.

Results & Findings

• Performance: Across a benchmark suite of real‑world R projects (average size ~2 k LOC), flowR built the full data‑flow graph in ≈576 ms.
• Developer Experience: Early user testing reported that the visual graph helped locate data‑origin bugs 30 % faster than manual code inspection.
• Extensibility: The plugin demo (custom lint rule for “hard‑coded file paths”) showed that new analyses can be added with < 50 lines of code and appear instantly in the IDE.
• Reproducibility Impact: By surfacing hidden data dependencies, flowR makes it easier to audit scripts before sharing or publishing, directly addressing reproducibility concerns in scientific workflows.

Practical Implications

• Faster Onboarding: New team members can grasp a legacy analysis pipeline by exploring the generated graph instead of wading through dense R code.
• Reduced Debugging Time: Inline value annotations let developers see the actual data flowing through a pipeline while they edit, cutting down trial‑and‑error cycles.
• Continuous Quality Gates: Linting rules can be enforced in CI pipelines (e.g., “no mutable global state”), improving code health across data‑science teams.
• Tool‑agnostic Integration: Because flowR talks via LSP, any editor that supports the protocol (including Emacs, Neovim, or JetBrains IDEs) can benefit with minimal setup.
• Custom Analyses for Domain Needs: Companies can ship proprietary plugins (e.g., GDPR‑compliant data‑lineage checks) without modifying the core flowR engine.

Limitations & Future Work

• Dynamic R Features: While flowR handles many dynamic constructs, highly reflective code (e.g., eval(parse(...))) may still evade static analysis.
• Scalability to Very Large Projects: The current evaluation focuses on projects up to a few thousand lines; megaprojects with tens of thousands of functions could push the incremental analysis beyond the sub‑second target.
• User Study Depth: The reported productivity gains stem from a small pilot; larger, controlled studies are needed to quantify impact across diverse teams.
• Future Directions: The authors plan to (1) extend support to other data‑science languages (Python, Julia), (2) improve handling of metaprogramming patterns, and (3) integrate with version‑control systems to visualize data‑flow changes over time.

Authors

• Florian Sihler
• Oliver Gerstl
• Lars Pfrenger
• Julian Schubert
• Matthias Tichy

Paper Information

• arXiv ID: 2604.15963v1
• Categories: cs.SE
• Published: April 17, 2026
• PDF: Download PDF