refactor: share findEnclosingTypeName helper between C# and Java analyzers - #654
Merged
askpt merged 1 commit intoSep 18, 2026
Conversation
Both csharpAnalyzer.getEnclosingTypeName() and javaAnalyzer.getMethodName() independently walked up the AST looking for a type-declaration node type and reading its name field, duplicating identical parent-walk/childForFieldName/ substring logic. Extracted the shared walk into complexityHelpers.ts as findEnclosingTypeName(), following the same pattern already used for isOutermostInSameOperatorChain/getBinaryLogicalOperator/hasLabelChild. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #654 +/- ##
==========================================
+ Coverage 98.72% 98.77% +0.05%
==========================================
Files 12 12
Lines 3912 3920 +8
Branches 441 438 -3
==========================================
+ Hits 3862 3872 +10
+ Misses 50 48 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
There was a problem hiding this comment.
🟢 Approved
The refactor preserves traversal and naming behavior with existing test coverage.
Pull request overview
Centralizes enclosing-type lookup while preserving C# and Java analyzer behavior.
Changes:
- Adds shared
findEnclosingTypeName(). - Replaces duplicated analyzer traversal logic.
File summaries
| File | Description |
|---|---|
complexityHelpers.ts |
Adds shared AST helper. |
csharpAnalyzer.ts |
Uses shared helper. |
javaAnalyzer.ts |
Uses shared helper for qualified names. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
askpt
approved these changes
Sep 18, 2026
askpt
deleted the
repo-assist/refactor-shared-enclosing-type-helper-20260918-138c0ce9c7a8f7f2
branch
September 18, 2026 06:26
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This pull request was created by Repo Assist, an automated AI assistant.
Summary
Extracts a shared
findEnclosingTypeName()helper intocomplexityHelpers.tsand updatescsharpAnalyzer.tsandjavaAnalyzer.tsto use it, removing a duplicated "walk up the AST to the enclosing type declaration" pattern.What was duplicated
Both
CSharpMetricsAnalyzer.getEnclosingTypeName()andJavaMetricsAnalyzer.getMethodName()independently walkednode.parentuntil hitting a type-declaration node type (from each analyzer's ownTYPE_DECLARATION_TYPESset), then read thenamefield and substringed it fromsourceText. The logic was byte-for-byte identical aside from formatting the returned name at the call site.This mirrors the duplication already centralized in prior runs for
isOutermostInSameOperatorChain,getBinaryLogicalOperator, andhasLabelChild— this was the one remaining "walk up to enclosing type" duplication not yet unified.Fix
Added
findEnclosingTypeName(node, typeDeclarationTypes, sourceText)tocomplexityHelpers.ts, taking theReadonlySet<string>of type-declaration node types as a parameter (matching the existing pattern for shared helpers). Both analyzers now call it and format the qualified name (ClassName.methodName) at their call sites. Purely mechanical, behavior-preserving — same node-type sets, samechildForFieldName("name")+ substring convention, same traversal order.Trade-offs
None — no behavior change, no new dependencies, three files touched (one new shared helper, two call-site simplifications).
Test Status
Coverage: 99.26% statements / 96.35% branches / 100% functions / 99.26% lines (thresholds 95/88/97/95 in
.c8rc.json— met, and slightly improved vs. baseline 99.2/96.2/100/99.2 sincejavaAnalyzer.tsis now fully branch-covered by existing tests).Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
releaseassets.githubusercontent.comTo allow these domains, add them to the
network.allowedlist in your workflow frontmatter:See Network Configuration for more information.
Add this agentic workflow to your repo
To install this agentic workflow, run