Skip to content

refactor: use NESTING_TYPES.has() in getComplexityIncrement for Java and Python#458

Merged
askpt merged 2 commits into
mainfrom
repo-assist/improve-nesting-types-increment-20260713-5678cf1bebee9248
Jul 17, 2026
Merged

refactor: use NESTING_TYPES.has() in getComplexityIncrement for Java and Python#458
askpt merged 2 commits into
mainfrom
repo-assist/improve-nesting-types-increment-20260713-5678cf1bebee9248

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

🤖 This is an automated pull request from Repo Assist.

Summary

Removes duplicated node-type listings in getComplexityIncrement() for the Java and Python analyzers, using the existing NESTING_TYPES static Set as the single source of truth.

Motivation

Both javaAnalyzer.ts and pythonAnalyzer.ts maintained the same list of node types in two places:

  1. NESTING_TYPES — a ReadonlySet<string> that controls nesting-level bumps for child traversal.
  2. getComplexityIncrement() — a switch statement that returns 1 + this.nesting for exactly those same node types.

Adding a new construct (e.g. a new loop type) required updating both locations. Missing one would silently produce wrong nesting increments.

Change

Replace the redundant switch cases with a single NESTING_TYPES.has() guard at the top of getComplexityIncrement(). The Set is an O(1) lookup — no performance impact.

Java (javaAnalyzer.ts): eliminates 9 case statements (8 nesting-group cases + the identical separate lambda_expression case)

Python (pythonAnalyzer.ts): eliminates 9 case statements (the 9 NESTING_TYPES cases)

Only flat increments (ternary_expression, elif_clause, else_clause, conditional_expression) and special-case increments (binary_expression, boolean_operator) remain in the switch.

No behavior change

The NESTING_TYPES sets are unchanged; getComplexityIncrement returns identical values for all inputs.

Test Status

npm run compile  ✅  (0 errors)
npm run lint     ✅  (0 warnings)
npm run test:unit  ✅  175 passing, 0 failing

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

  • releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@1c6668b751c51af8571f01204ceffb19362e0f66

…and Python

Eliminate duplication between NESTING_TYPES Set and the getComplexityIncrement
switch-case in javaAnalyzer.ts and pythonAnalyzer.ts.

Previously, each file maintained two lists of the same node types: once in
NESTING_TYPES (used to bump nesting level) and again as switch cases in
getComplexityIncrement (to return 1 + nesting). This made the two sources
easy to get out of sync when adding new constructs.

Now getComplexityIncrement checks NESTING_TYPES.has() first — a single O(1)
Set lookup — and returns 1 + nesting for all structural-increment nodes.
Only the flat and special-case increments remain in the switch.

No behavior change; all 175 unit tests pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@askpt askpt changed the title [repo-assist] refactor: use NESTING_TYPES.has() in getComplexityIncrement for Java and Python refactor: use NESTING_TYPES.has() in getComplexityIncrement for Java and Python Jul 17, 2026
@codecov

codecov Bot commented Jul 17, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.50%. Comparing base (a91c6b9) to head (41eb354).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #458      +/-   ##
==========================================
- Coverage   81.54%   81.50%   -0.05%     
==========================================
  Files          13       13              
  Lines        4276     4265      -11     
  Branches      441      428      -13     
==========================================
- Hits         3487     3476      -11     
  Misses        787      787              
  Partials        2        2              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@askpt
askpt marked this pull request as ready for review July 17, 2026 11:45
@askpt
askpt self-requested a review as a code owner July 17, 2026 11:45
Copilot AI review requested due to automatic review settings July 17, 2026 11:45

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR refactors the Java and Python cognitive complexity analyzers to remove duplicated “structural increment” node-type lists by using each analyzer’s existing NESTING_TYPES Set as the single source of truth in getComplexityIncrement().

Changes:

  • Java: Replace the structural switch cases in getComplexityIncrement() with an early NESTING_TYPES.has(node.type) guard.
  • Python: Replace the structural switch cases in getComplexityIncrement() with an early NESTING_TYPES.has(node.type) guard.
  • Update the related doc comments to clarify that structural increments are driven by NESTING_TYPES.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
src/metricsAnalyzer/languages/pythonAnalyzer.ts Uses NESTING_TYPES.has() to handle structural increments in getComplexityIncrement() and updates the method’s documentation accordingly.
src/metricsAnalyzer/languages/javaAnalyzer.ts Uses NESTING_TYPES.has() to handle structural increments in getComplexityIncrement() and updates the method’s documentation accordingly.

@askpt
askpt merged commit c7da834 into main Jul 17, 2026
18 checks passed
@askpt
askpt deleted the repo-assist/improve-nesting-types-increment-20260713-5678cf1bebee9248 branch July 17, 2026 12:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants