5 exercises on adjective–noun collocations used in code review, architecture discussions, and engineering culture: the terms that distinguish fluent engineering English from guesswork.
Key code quality collocations in this set
clean code — the Robert C. Martin standard; not "neat" or "tidy"
dead code — unreachable; caught by linters; not "unused" or "orphan"
defensive programming — anticipate failure, never trust input
testable — designed for isolation; not "verifiable" or "checkable"
0 / 5 completed
1 / 5
A senior engineer reviews a PR:
"Good PR! The logic is clear, functions are short, and names are self-explanatory. This is a great example of ___ code."
Which adjective collocation describes code that is easy to read, well-named, and self-documenting?
Clean code is the established term — popularised by Robert C. Martin's influential book Clean Code (2008). It refers to code that is easy to read, understand, and modify: short functions, meaningful names, no duplication, minimal comments (because the code speaks for itself), and proper abstractions.
Why the others fail:
neat code — used informally but not a technical collocation
tidy code — informal British English; not a term of art in software engineering
polished code — suggests finishing touches; not a recognised category
"Lines 47–89 are never called — they were part of a feature that was removed last quarter but the code wasn't deleted. This is pure ___ code."
Which adjective describes code that can never be reached or executed?
Dead code is the precise technical term for code that is present in the source but can never be executed — either because the control flow can never reach it, or because the function is never called. It is a recognised code smell in static analysis and linting tools (ESLint, SonarQube, etc.).
Why the others fail:
orphan code — not a standard term; "orphan" is used in other contexts (orphan process, orphan branch)
unused code — descriptively accurate but not the canonical technical collocation
zombie code — informal slang; not used in professional contexts or linting rules
Types of dead code:
Unreachable code after a return statement
Functions that are defined but never called
Variables that are assigned but never read
Code guarded by a condition that is always false
Common collocations:remove dead code, dead code elimination (compiler optimisation), dead code detection.
3 / 5
An architect describes an engineering practice:
"We write all input validation assuming external data is hostile. This is called ___ programming — never trust, always verify."
Which adjective describes the practice of anticipating and handling errors, invalid inputs, and misuse?
Defensive programming is the established term for a style of coding that anticipates failures, validates all inputs, handles edge cases explicitly, and never assumes that callers will behave correctly. It is a proactive approach to software robustness.
Why the others fail:
protective programming — not a standard collocation in software engineering
cautious programming — not a recognised term of art
secure programming — overlaps in intent but specifically means writing code to prevent security vulnerabilities (different technical domain)
Defensive programming practices include:
Validating all function arguments
Using assertions to catch programmer errors early
Handling all exception types explicitly
Avoiding assumptions about data types, ranges, or formats
Common collocations:defensive coding, defensive design, defensive check.
4 / 5
A tech lead describes the project's architecture goal:
"Each service should be independently deployable and testable. We want a ___ design — changes to the checkout service should never require changes to the user service."
Which adjective describes components with minimal interdependencies?
Loosely coupled is the canonical term. Coupling refers to the degree of interdependence between software components. Loosely coupled components interact through well-defined interfaces, with minimal knowledge of each other's implementation. This enables independent development, testing, and deployment.
Why the others fail:
weakly coupled — not used in software engineering; "weak" in programming usually refers to weak references in memory management
softly coupled — not a recognised term
lightly coupled — not standard; sounds informal
The canonical pair:
loosely coupled — low interdependency (good)
tightly coupled — high interdependency (often a code smell)
Related collocations:loosely coupled architecture, loose coupling and high cohesion (SOLID/design principle), loosely coupled services (microservices).
5 / 5
A developer advocates for writing tests before code:
"If we design our classes to be ___, we can swap out dependencies with mocks and verify behaviour in isolation without a database."
Which adjective describes code that can be verified in isolation using test doubles?
Testable is the established collocation. Testable code is designed so that its behaviour can be verified in isolation — typically through dependency injection, pure functions, and avoidance of global state. Testability is a key quality attribute in modern software engineering and is directly related to design patterns like Dependency Inversion (SOLID's D).
Why the others fail:
verifiable — used in formal methods and security contexts; not the everyday term in software testing
checkable — not a recognised technical term in this context
inspectable — used in UI testing (e.g., React's test utils) but not the general term for code design
What makes code testable:
Dependencies are injected, not hard-coded
Functions are pure (same input = same output, no side effects)
Classes have single responsibilities
No hidden global state
Common collocations:testable code, testable design, write testable code, testable architecture.