Skip to content

Refactor (packages/opencode/src/tool/edit.ts:69): Function with high complexity (count = 34): execute - #174

Open
cmu-ccao2 wants to merge 4 commits into
CMU-313:mainfrom
cmu-ccao2:P1B
Open

Refactor (packages/opencode/src/tool/edit.ts:69): Function with high complexity (count = 34): execute#174
cmu-ccao2 wants to merge 4 commits into
CMU-313:mainfrom
cmu-ccao2:P1B

Conversation

@cmu-ccao2

@cmu-ccao2 cmu-ccao2 commented Sep 8, 2026

Copy link
Copy Markdown

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue:
#150

Full path to the refactored file:
packages/opencode/src/tool/edit.ts

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)
I think the file handle opencode editing and creating new files based on the execute() function I worked on.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
Refactored execute() by adding 3 closures and a helper function in place of a single function with many and potentially complicated pathing.

Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)
Function with high complexity (count = 34): execute in edit.ts

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
I think the function was just very long and complicated and doing a lot. If something where to go wrong involving the function, it may take a long time of code tracing to see which path the issue took and how it failed to do the correct thing.

What changes did you make to resolve the issue?
Broke it up into smaller pieces / closures / help functions.

How do your changes improve maintainability? Did you consider alternatives?
When code tracing bugs, I think it will be easier because you will know which function it failed in and be able to start debugging from there and not have to be distracted by code that the bug did not encounter. I did not consider alternatives, in large part because I don't know what other options there are to making it less complex of a function than to just break it up into pieces.

3. Validation

How did you validate that the change is correct?
Passed bun lint and bun test on the existing test cases and a newly made test suite for execute() specifically.
image
image
image

Attach a screenshot of the test coverage showing the lines were executed by the tests.
image
^ bun test against all of packages/opencode
image
^ bun lint against the entire codebase (the gradescope requirement feels like it implies it needs the previous 2 images, but im not sure why)

image it is a pretty big file, so execute() makes up a small portion of it image image image My changes are only made in the first 220 lines of the file, and all of those lines are covered.

Attach a screenshot showing the tests that cover the change passing during CI
image

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.
before:
image

after:
image
Function with high complexity (count = 34): execute is gone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant