Table of Contents
When you join a large codebase and need to figure out the “right” way to do something, don’t guess. Don’t check the docs. Let the codebase vote.
The Scenario
You’re working in a Laravel app and need to get the current locale. Quick, which one do you use?
// Option A
App::getLocale()
// Option B
app()->getLocale()
// Option C
config('app.locale')
They all work. But in a codebase with 200+ files touching locales, consistency matters more than personal preference.
grep Is Your Democracy
grep -r "App::getLocale" --include="*.php" | wc -l
# 96
grep -r "app()->getLocale" --include="*.php" | wc -l
# 19
grep -r "config('app.locale')" --include="*.php" | wc -l
# 3
The vote is 96-19-3. App::getLocale() wins by a landslide. That’s what you use. Discussion over.
Why This Works
The dominant pattern in a mature codebase exists for a reason. Maybe it was a conscious decision. Maybe it evolved naturally. Either way, it represents what the team actually does, not what someone thinks they should do.
Following the majority means:
- Your code looks like the rest of the codebase
- grep and find-replace operations work consistently
- New developers see one pattern, not three
- Code reviews go faster because there’s nothing to debate
More Examples
This technique works for any “multiple valid approaches” question:
# String helpers: str() vs Str:: vs helper
grep -r "Str::" --include="*.php" | wc -l
grep -r "str_" --include="*.php" | wc -l
# Config access: config() vs Config::
grep -r "config(" --include="*.php" | wc -l
grep -r "Config::" --include="*.php" | wc -l
# Route definitions: Route::get vs Route::resource
grep -r "Route::get" routes/ | wc -l
grep -r "Route::resource" routes/ | wc -l
When to Override the Vote
The only time you should go against the majority is when the dominant pattern is actively harmful β deprecated functions, security issues, or patterns that cause real bugs. In those cases, file a tech debt ticket and migrate everything at once. Don’t create a third pattern.

Leave a Reply