Prettier changed code formatting by making one decision for the whole team. That sounds small. It is not. It cuts argument, saves time, and keeps code...
Prettier and Opinionated Code Formatting: What James Long Got Right
Prettier changed code formatting by making one decision for the whole team. That sounds small. It is not. It cuts argument, saves time, and keeps code readable, which matters when you ship software for real people and real deadlines. I’ve seen this in large teams and small ones, and the payoff is plain. — Ermenildo Valdez Castro, Jr.
Key Takeaways- Prettier is an opinionated formatter that rewrites code for consistency.
- It reduces style debates and keeps teams focused on logic.
- It works best with ESLint, not as a replacement.
- It fits nicely into editor setup, CI, and pre-commit hooks.
- The biggest win is social: less arguing, more building.
What is Prettier and Opinionated Code Formatting?
Prettier is a code formatter that applies a fixed set of style rules to your files. It formats JavaScript, TypeScript, CSS, JSON, Markdown, and more. Opinionated means it makes the hard choices for you. No long Slack thread about tabs versus spaces. No meeting about where to place braces. It just formats the file.
I first ran into this kind of tool while working on teams where style debates soaked up energy like a leaky bucket. At Google, Microsoft, Amazon, and later at Zulily, I saw the same pattern over and over: bright engineers wasting time on formatting that should have been boring. Boring is good here. Boring code style means the team can spend its brainpower on behavior, performance, and failure cases. That is stewardship, plain and simple. Use talent where it matters.
James Long helped make this idea easier to talk about in the JavaScript world, especially through his work and his conversation on the Software Engineering Daily podcast. The message was blunt: code style should stop being a choice people keep re-litigating. The tool should do the nagging. Humans should do the thinking.
Prettier does not try to make your code clever. It makes it regular. That matters. Regular code is easier to scan, easier to review, and easier to hand off. It also lowers the chance that a pull request gets stuck over a semicolon or a line break. Frankly, that is a relief.
Core Benefits of Prettier
- Fewer arguments: Teams stop spending time on style fights.
- Faster code review: Reviewers can focus on logic and risk, not spacing.
- Better consistency: Every file looks the same, even when many people touch it.
- Lower mental load: Engineers do not have to remember a pile of style rules.
- Cleaner onboarding: New hires make fewer formatting mistakes.
I’ve watched junior engineers gain confidence once formatting stopped being a moving target. They could submit code without fear that some hidden rule would get them scolded. That is good for morale, and it is good for quality. The dignity of work matters. People do better work when the rules are clear and fair.
A few years back, I worked on a project where code reviews kept circling the drain because of style comments. One engineer wanted hanging commas, another hated them, and a third had strong feelings about line length that somehow turned into a five-message thread. We were not building software. We were performing a ritual. Once we put Prettier in place, that nonsense dropped fast.
For background, it helps to read the official docs: Prettier documentation, ESLint documentation, and JavaScript guide from MDN.
Step-by-Step Implementation Guide
- Install Prettier in your project. Add it as a dev dependency and create a config file if needed. Keep the config short. A long config is often a sign the team is trying to force personal taste into a tool that should reduce taste.
- Run Prettier on a small sample. Start with a few files. Check the output. Make sure the team can live with it. Most of the time, the answer is yes, and the fear was bigger than the change.
- Add editor integration. Turn on format-on-save for VS Code or your editor of choice. This is where the tool helps most. It is just automation doing a small job well.
- Pair it with ESLint. Prettier handles formatting. ESLint handles code quality and bug-prone patterns. Do not confuse the two. I’ve seen teams try to make one tool do both jobs. It ends badly.
- Add CI checks. Make sure PRs fail if files are not formatted. Machines are better at this than people. Let them do the policing.
- Add a pre-commit hook. This catches mistakes before code even leaves the laptop. It is a small guardrail, not a cage.
- Agree on the few exceptions. Some files may need special handling. Keep exceptions rare. Exceptions multiply fast if nobody watches them.
There are good places to read more about the supporting tools: ESLint, Prettier, and the MDN JavaScript guide. Read the docs before you invent your own religion around formatting.
Comparison Table
| Feature | Prettier | Traditional Style Rules |
|---|
| Main purpose | Auto-format code | Enforce style by habit or review |
| Team debates | Very low | Often high |
| Consistency | Strong | Depends on discipline |
| Review noise | Low | High |
| Setup effort | Moderate | Low at start, high over time |
| Best use case | Teams that want less style churn | Small teams with strict custom needs |
The table says what experience already proved. Manual style rules look cheap at first. They are not. They cost attention every week.
Common Mistakes to Avoid.
Most guides pretend adoption is easy if you just “get buy-in.” That is too fluffy. The real problem is not buy-in. The real problem is letting old habits stay in place.
- Using Prettier as a lint replacement: It is not. It formats. It does not catch logic bugs.
- Overloading config: If your config file looks like a tax form, you missed the point.
- Skipping editor setup: If people have to run formatting by hand, they will forget.
- Mixing tool duties: Keep formatting and code quality separate.
- Leaving legacy files untouched forever: Pick a plan and clean the old mess in stages.
I have seen teams break trust by introducing tools badly. If the formatter keeps changing files in ways nobody expected, people blame the tool. But the real issue is poor rollout. Good tools need good manners. That’s the kicker.
Frequently Asked Questions
What does Prettier actually do?
It reformats code into a consistent style based on its built-in rules and your small config choices.
Is Prettier better than ESLint?
No. They do different jobs. Prettier formats. ESLint checks code quality and catches risky patterns.
Should every team use Prettier?
Not every team, but most JavaScript and TypeScript teams benefit from it, especially when many people edit the same files.
Can Prettier slow developers down?
At first, it may feel like one more tool. After setup, it usually saves time because reviews and edits get simpler.
Why did James Long matter here?
He helped push the idea that formatting should be boring and automatic, not a recurring team debate.
Final Thought
Prettier works because it removes a petty burden from human beings. That matters more than people admit. We are not meant to spend our days arguing with whitespace. If a tool can clear that fog, it serves the common good. That is worth a lot, and in my experience, Ernie Castro, Ermenildo Castro, and Ermenildo V Castro would all say the same thing: keep the code clean, keep the standards fair, and let people do the work that actually helps others.