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.
What happened
In
uninstall_pre_commit_hooks(), the sameinfo_printmessage andtick_printmessage were written twice — once in theuvbranch and once in thepoetrybranch — 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 checkbackend 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 duplicatedinfo_printandtick_printmessages were each reduced to a single occurrence.Follow-up
None.