principleModeratepending
Principle: Convention over configuration
Viewed 0 times
conventionconfigurationdefaultsframeworkproductivity
Problem
Requiring explicit configuration for every aspect of a framework or library makes setup slow and error-prone. Users must learn and decide on many options before doing anything useful.
Solution
Provide sensible defaults that work out of the box, only require config for deviations:
Examples:
pages/about.tsx -> /about route (no router config needed)
class User -> users table (no explicit table name)
*.test.ts or __tests__/ (no test config listing each file)
Dev server on 3000, DB on 5432 (no config unless changed)
Principles for good defaults:
Anti-patterns:
Examples:
- File-based routing (Next.js, Astro):
pages/about.tsx -> /about route (no router config needed)
- Database table from model name:
class User -> users table (no explicit table name)
- Test file discovery:
*.test.ts or __tests__/ (no test config listing each file)
- Default ports:
Dev server on 3000, DB on 5432 (no config unless changed)
Principles for good defaults:
- 80% of users should never need to configure it
- Defaults should be safe and predictable
- Always allow overriding for the 20% who need it
- Document what the defaults are
- Don't change defaults in minor versions (breaking)
Anti-patterns:
- Requiring 50-line config file before 'hello world'
- Implicit behavior that can't be overridden
- Magic that varies by environment with no way to inspect it
- Defaults that are insecure (open ports, no auth)
Why
Good defaults reduce cognitive load and time to productivity. They encode best practices so each user doesn't have to rediscover them.
Revisions (0)
No revisions yet.