principleModeratepending
Principle: Explicit is better than implicit (Zen of Python applied broadly)
Viewed 0 times
explicitimplicitreadabilitydependenciesnamingclarity
Problem
Code that relies on implicit behavior, magic conventions, or hidden side effects is hard to understand, debug, and maintain.
Solution
Prefer explicit, visible behavior over magic:
Bad: def process(): db = get_global_db()
Good: def process(db: Database):
Bad: result = api_call() or default_value
Good: result = api_call(); if result is None: raise ValueError('API returned None')
Bad: Class name UserSerializer auto-maps to User model
Good: class UserSerializer: model = User
Bad: create_user('Alice', True, False, 30)
Good: create_user(name='Alice', admin=True, active=False, age=30)
Bad: from utils import *
Good: from utils import validate_email, format_name
Bad: process(data) # mutates data in place, returns None
Good: result = process(data) # returns new data, original unchanged
- Explicit dependencies over global state:
Bad: def process(): db = get_global_db()
Good: def process(db: Database):
- Explicit error handling over silent failures:
Bad: result = api_call() or default_value
Good: result = api_call(); if result is None: raise ValueError('API returned None')
- Explicit configuration over convention:
Bad: Class name UserSerializer auto-maps to User model
Good: class UserSerializer: model = User
- Named arguments over positional:
Bad: create_user('Alice', True, False, 30)
Good: create_user(name='Alice', admin=True, active=False, age=30)
- Explicit imports over wildcard:
Bad: from utils import *
Good: from utils import validate_email, format_name
- Return values over side effects:
Bad: process(data) # mutates data in place, returns None
Good: result = process(data) # returns new data, original unchanged
Why
Explicit code can be understood by reading it. Implicit code requires knowing conventions, framework magic, or runtime behavior.
Revisions (0)
No revisions yet.