G22: Logical to Physical Dependencies
Never let a module silently assume a value from another — make every dependency explicit and declared in code.
The Problem of Silent Assumptions
G22: A logical dependency is an assumption your code makes about another module's state without declaring it in code. Module A uses a constant it assumes is defined in module B. If B changes that constant, A breaks silently at runtime, not at compile time. Logical dependencies are invisible to the compiler, the linter, and the reviewer — they are bugs waiting for a version bump. Physical dependencies are declared: your code imports the value, receives it as a parameter, or references a shared source — and the build system can verify it.
Making Dependencies Explicit
The rule: if your code's correctness depends on a value, that value must appear explicitly in your code — not be assumed. Strategies: (1) pass the value as a parameter; (2) inject the dependency; (3) import from a shared constants module. Every duplicated constant is a hidden logical dependency waiting to diverge. When you see the same magic number in two places, one of them will be updated and the other won't.
Code Challenge
Replace duplicated constants with a single shared source imported by all modules.
💡Key takeaway
G22: If your code's correctness depends on a value, import it — don't assume it. Logical dependencies are invisible bugs; physical dependencies are verifiable facts.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: Every duplicated constant is a hidden logical dependency waiting to diverge. Create a shared constants module and import from it — that import line is the physical declaration of the dependency.
✗ Your version