5 exercises on the precise vocabulary of code quality discussions — cyclomatic complexity, extract method, coupling, dead code, and SOLID principles. These terms appear in every serious code review.
0 / 5 completed
1 / 5
A reviewer comments: "This function has high ___ complexity — it has 14 independent paths and is very hard to test."
Which adjective correctly names this code quality metric?
Cyclomatic complexity is the standard software metric for measuring the number of independent paths through a piece of code. It was introduced by Thomas McCabe in 1976 and is widely used in code review and static analysis tools (SonarQube, CodeClimate, etc.).
How it works:
Every branch (if, else, for, while, case) adds 1 to the complexity score
A function with a cyclomatic complexity of 1 has a single straight path — no branches
A function with a score of 14 has 14 independent execution paths — very hard to test and maintain
Industry guidelines:
1–10 — simple, low risk
11–20 — moderate complexity, worth refactoring
21+ — high risk, difficult to test, should be broken up
In code review:
"This has high cyclomatic complexity — can we break it into smaller functions?"
"SonarQube is flagging cyclomatic complexity of 18 on this method."
2 / 5
A reviewer suggests: "Let's ___ this validation logic into a separate helper function so it can be reused."
Which verb is the standard refactoring term for this action?
Extract is the standard refactoring verb for moving a piece of code into a new, separate function or method.
"Extract Method" is one of the most fundamental refactoring patterns, popularised by Martin Fowler's book Refactoring: Improving the Design of Existing Code. Modern IDEs (VS Code, IntelliJ, PyCharm) have an "Extract Method" command built in.
Common refactoring vocabulary:
extract a method / function / class — move logic to a new unit
inline a function — the opposite; fold a function back into its call site
rename — change the name of a variable, function, or class
move — relocate code to a different file or module
decompose — break a complex function into smaller parts
In code review:
"Can you extract this into a `formatDate` utility?"
"I'd suggest extracting the validation logic — it appears in three places."
3 / 5
A tech lead reviews a module and notes: "The code has tight ___ between the payment service and the user service — they're very hard to test in isolation."
Which noun correctly describes this architectural problem?
Coupling is the standard software engineering term for the degree of dependency between two modules or components.
Tight coupling = two modules are highly interdependent; changes in one affect the other, making them hard to test, maintain, or replace independently.
Loose coupling = modules interact through well-defined interfaces; they can be changed or replaced independently. This is the goal of good software design (SOLID principles, microservices, dependency injection).
Related vocabulary:
cohesion — how focused a single module is on one task (high cohesion = good)
coupling — how connected two modules are (low coupling = good)
"tightly coupled" — the adjective form: "These two services are tightly coupled."
"decouple" — the verb: "We need to decouple the payment module from user management."
In code reviews: "This creates tight coupling — consider injecting the dependency instead."
4 / 5
In a code review, a developer writes: "We should ___ the dead code before this PR goes to production — it's cluttering the module."
Which verb is most natural here?
Remove is the most natural and widely-used verb in professional engineering communication when referring to eliminating dead code from a codebase.
What is dead code? Code that is never executed — unreachable branches, unused variables, commented-out blocks, or orphaned functions that are no longer called anywhere.
Verb comparison:
remove dead code — the standard professional term: clear, neutral, widely used
delete dead code — also correct and common; slightly more literal (as in deleting lines)
clean up dead code — acceptable but "clean up" implies tidying rather than specifically removing unused code
strip dead code — used in compiler/build tooling contexts ("the build tool strips dead code"), but sounds unusual when a developer says it in a PR comment
Related patterns:
"Remove unused imports before merging."
"This function is dead code — delete it."
"Let's clean up the commented-out blocks."
5 / 5
A reviewer comments: "This class handles data fetching, validation, formatting, and logging. It violates the ___ principle."
Which design principle has been violated?
Single Responsibility Principle (SRP) is the correct term — the first of the five SOLID design principles.
SRP states: A class (or module, function) should have only one reason to change — it should be responsible for only one thing.
Violation: A class that handles data fetching, validation, formatting, AND logging has multiple responsibilities. Changes to any one area (e.g., a new logging format) affect the entire class, making it fragile and hard to test.
The SOLID principles:
S — Single Responsibility Principle
O — Open/Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle
In code reviews:
"This violates SRP — the class is doing too much."
"Extract the validation logic into its own service — Single Responsibility."
Note: "Single Purpose" and "Single Concern" are not the standard names — always use "Single Responsibility Principle" or the abbreviation "SRP".