Skip to main content
Cyclomatic complexity is a measure of how many independent decision paths run through a function. Every if, for, while, case, and logical operator (and, or) adds a branch — and each additional branch is another path that needs testing and another place where a bug can hide. BugViper calculates this score for every function in your codebase at ingestion time and stores it directly on the Function node in the knowledge graph.

​
When complexity is calculated

Complexity scores are computed once, at ingestion time, as part of the Tree-sitter AST parsing step. You don’t need to request an analysis — by the time a repository finishes indexing, every function already has its complexity score attached. The scores are immediately available via the API and used by the AI review agent on every PR review. If you re-ingest a repository (for example, after significant refactoring), complexity scores are recalculated for all functions.

​
Risk scoring table

BugViper uses the following thresholds to classify functions by risk:
Cyclomatic complexityRisk level
1–5Simple
6–10Moderate
11–20Complex — refactor candidate
20+High risk — bugs likely here
A score of 1 means the function has a single straight-line path with no branches. A score of 20+ means the function has at least 20 independent paths — each one a potential source of untested behavior.
Functions scoring 20 or higher are statistically the most bug-prone code in your repository. Treat them as refactor candidates before shipping.

​
Querying complexity via the API

To retrieve the highest-risk functions in an indexed repository, call the complexity endpoint: 
GET /api/v1/query/code-finder/complexity/top
  ?repo_owner=your-org
  &repo_name=your-repo
  &limit=10
The response returns the top functions sorted by cyclomatic complexity descending, with their file path and line number so you can navigate directly to the source. To look up the complexity of a specific function by name: 
GET /api/v1/query/code-finder/complexity
  ?function_name=parse_unified_diff
  &repo_owner=your-org
  &repo_name=your-repo

​
How the AI reviewer uses complexity

The review agent’s Explorer node has direct access to complexity data through two tools: get_complexity (for a named function) and get_top_complex_functions (for the highest-risk functions in the repo). When the agent is reviewing a diff that touches a high-complexity function, it factors this in when assessing the risk of the change — a modification to a function with a score of 18 gets more scrutiny than the same change in a function with a score of 3. Complexity is one of several signals the agent considers alongside call chain analysis, class hierarchy, and the blast radius of any changed symbols.

​
Practical use: pre-release risk triage

Complexity scores give you a fast way to prioritize code review effort before a release. Instead of reviewing all changed files equally, you can:
  1. Call GET /api/v1/query/code-finder/complexity/top to get the top 10 most complex functions across the repository.
  2. Cross-reference that list with your changed files to identify which high-complexity functions were modified in the release branch.
  3. Focus manual review time on those functions, or trigger a @bugviper full review on the PR.
Aim to reduce any function scoring 11 or higher before it ships. Refactoring a complex function into smaller, single-responsibility pieces is one of the most reliable ways to reduce bug density.