Skip to content

Capture control flow (if/else, loops) as first-class graph nodes #80

Description

@smochan

The idea

Capture control flow — if/else, for/while/else, try/except — as first-class nodes in the graph, the same way we already capture imports, calls, and call-site arguments.

Why it matters

Most code graphs stop at structure: who imports what, who calls what. That says nothing about behavior. Once branches and loops are in the graph, an AI assistant (or an audit pass) can ask "does this handle the empty case?" or "is there a loop here that can't terminate?" — questions imports and call edges can't answer. This is the core "context-rich, not just fast" thesis: richer graph, richer questions.

Sketch of an approach

  • Add new NodeKind values in codegraph/graph/schema.py (e.g. BRANCH, LOOP) plus edges linking each to its enclosing FUNCTION/METHOD.
  • Extract them in the tree-sitter parsers, starting with codegraph/parsers/python.py (the v1 reference), then TS/JS/Go.
  • Follow the existing intra-procedural data-flow pattern (DATA_ASSIGN / DATA_ARG / DATA_RETURN) for how body-level constructs are already walked and emitted.

Acceptance criteria

  • BRANCH / LOOP (or equivalent) nodes appear in the graph for Python functions
  • Each control-flow node links to its enclosing function/method
  • A fixture test asserts the nodes/edges for a small sample file
  • Extraction degrades gracefully on unsupported languages (no crash)

Part of the build-in-public roadmap. Discussed on LinkedIn (link to follow).

Metadata

Metadata

Assignees

No one assigned

    Labels

    build-in-publicTracked in public alongside a postenhancementNew feature or requestroadmapPlanned build-in-public roadmap item

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions