Convention Over Configuration

“Decrease the number of decisions that a developer using the framework is required to make without losing flexibility.”

Systems should have sensible defaults. Developers only need to specify the “unconventional” bits.

When to use

When designing frameworks, libraries, or internal scaffolding for a large project.

Why it matters

Productivity: Developers write less code.
Consistency: Everyone follows the same structure because it’s the path of least resistance.
Onboarding: Less to learn if things “just work” where you expect them to.

Signs of Violation

Massive XML/JSON configuration files required just to boot the app.
Explicitly mapping every class to a database table even when names match identical.

Explanation

Problem

Explicitly configuring every single detail (like “Class ‘User’ maps to Table ‘users’”) is tedious and redundant.

Solution

Assume the obvious. If I name a class User, assume the table is users. Only ask me to configure it if the table is named legacy_usr_tbl.

Real world analogy

Traffic laws. We have a convention: Drive on the right side of the road. We don’t need a sign every 10 meters saying “Stay Right”. We only need signs for exceptions (“One Way”, “Keep Left”).

Pros and Cons

Pros	Cons
Speed Less boilerplate	“Magic” behavior can be confusing if you don’t know the convention

Comparison

Explicit Configuration: The opposite. Better for clarity in complex/rare scenarios, worse for productivity in common ones.