Skip to content

agent: structure if-else nesting to avoid duplicated string literals #1869

@nathanjmcdougall

Description

@nathanjmcdougall

What happened

In uninstall_pre_commit_hooks(), the same info_print message and tick_print message were written twice — once in the uv branch and once in the poetry branch — because the outer if-else branched on the backend, and the shared guard condition (_is_git_repo()) was nested separately inside each arm.

Root cause

When a guard condition (like "is git available?") applies equally to multiple branches of an outer if-else, nesting it inside each branch independently leads to duplicated code. The duplication was introduced because the backend dispatch was written at the outer level first, making each arm independently responsible for its own guard logic.

Generalised principle

When a guard condition applies to a group of branches (e.g. multiple enum values), always check that guard at the outer level — using a combined membership check such as if backend in (A, B): — before branching on individual values. Nesting shared conditions inside each branch individually causes string and logic duplication that is easy to miss and hard to keep in sync. If you notice the same string literal or logic block appearing in two sibling branches of an if-else, treat that as a signal to restructure: hoist the shared condition to the outer level, and move the distinguishing logic to the inner level.

Resolution

Refactored uninstall_pre_commit_hooks() to first check backend in (BackendEnum.uv, BackendEnum.poetry), then check _is_git_repo() once in that outer block, then branch on the specific backend for the differing uninstall logic. The duplicated info_print and tick_print messages were each reduced to a single occurrence.

Follow-up

None.

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions