Code Smell 29 — Settings/Configs
Changing system behavior in a control board is the customer’s dream. And the software engineer’s nightmare.

Problems
- Duplicated Code
- If Pollution
- Global usage
- Coupling
- Testability and explosion of testing scenarios.
- Complexity
Solutions
- Avoid Settings
- Create polymorphic objects. Inject them externally.
Sample Code
Wrong
Right
Detection
This is an architectural pattern so it should be controlled/avoided by design policies.
Examples
- External Connection Settings
- User settings
- Feature Toggle
Exceptions
- Sometimes we use Feature togging as a safeguard mechanism. This is acceptable in a legacy system. These toggles should be very short-lived in a CI/CD system.
- Hyper parameter settings should be managed by configuration objects.
Tags
- Globals
Conclusion
Setting runtime behavior is great for software systems.
We should configure our objects, so they can behave in different ways, and we should achieve it in an explicit way with explicit behavioral objects.
In this way, our code will be more declarative, clean and testable. It is not as easy as adding an IF Statement. This kind of lazy developers bring lots of coupling and unexpected issues on our systems.
A system with 300 Boolean configurations has more test combinations (2^300), than the number of atoms in the universe (10^80).
Also known as
- Feature Toggles
More Info
Simplicity is the soul of efficiency.
Austin Freeman
This article is part of the CodeSmell Series.