Prettier Explained: Formatting Code So Nobody Argues About It

Introduction

Ask five developers how to format code and you'll get six opinions: tabs or spaces, single or double quotes, semicolons or not, trailing commas or not. Teams have burned entire meetings on these questions — and code reviews full of formatting comments. Prettier ends the argument by removing it: it reformats your code automatically, in one consistent style, every time.

Opinionated by design

Prettier is deliberately opinionated: it offers very few options, and its defaults are the point. Run it on any file and it rewrites the formatting — indentation, quotes, line breaks, trailing commas — to the same style, regardless of who wrote the code:

// Before: inconsistent, hard to scan
function greet( name, greeting ) { return greeting + ", " + name + "!"; }
// After Prettier: one style, every file, every author
function greet(name, greeting) {
  return greeting + ", " + name + "!";
}

It doesn't change what the code does — only how it looks. And because it runs automatically on save or on commit, formatted code is never a thing anyone has to think about or comment on in review.

Prettier vs ESLint: different jobs

Beginners often confuse the two tools from this batch, so the distinction matters: ESLint finds bugs and enforces code quality rules; Prettier only formats. They are designed to work together — ESLint's formatting rules are turned off when Prettier is present, so the tools never fight. The standard setup is both: Prettier makes code look consistent, ESLint makes it correct. One command formats, the other lints, and together they remove an entire category of review comments.

The honest trade

Prettier's opinions won't match everyone's taste — you may hate its line-breaking choices, and there is no option to change most of them. That is the trade, and it is worth it: consistency across a codebase matters more than any individual's preference, and the time saved in reviews and arguments dwarfs the annoyance of an unfamiliar style. Teams that adopt Prettier rarely go back, because the formatting argument simply disappears.

Takeaway

Prettier formats code automatically in one consistent style, ends style arguments by removing the choice, and pairs with ESLint — one formats, the other finds bugs. Adopt both, and code reviews get back to what actually matters: what the code does.

Comments

Post a Comment

Popular posts from this blog

Swift Explained: Apple's Language for iPhone, Mac, and More

Introduction Swift is Apple's language for its platforms: iPhone, iPad, Mac, Apple Watch, and Apple TV. Introduced in 2014 to replace the older Objective-C, it was designed to be safe, fast, and — unusually for a systems language — genuinely pleasant to read and write. Even if you never ship an app, Swift teaches one idea every developer should understand: optionals. Optionals: saying "this might be missing" Most bugs in app development come from one cause: code assuming a value exists when it does not. Swift makes that assumption impossible to hide. A value that might be missing is wrapped in an Optional, and you must unwrap it before use. var nickname: String? = nil nickname = "Waqas" if let name = nickname { print("Hello, \(name)!") } else { print("No nickname set.") } String? means "a String, or nothing". The if let unwraps it safely: inside the block, name is guaranteed to exist. There is no way to accidentally us...
Read more

Flutter Explained: One Codebase, Every Screen

Introduction Flutter is Google's framework for building apps from a single codebase: write once in Dart, and ship to iOS, Android, web, Windows, macOS, and Linux. It powers apps from Google Pay to the New York Times crossword app. Its core idea is simple and radical: everything on screen is a widget, and the interface is rebuilt from data whenever that data changes. Everything is a widget In Flutter, there are no separate concepts for layout, styling, and controls — everything is a widget, nested inside other widgets like HTML elements, but in code: import 'package:flutter/material.dart'; class Greeting extends StatelessWidget { @override Widget build(BuildContext context) { return Center( child: Text( 'Hello, Sara!', style: TextStyle(fontSize: 24, color: Colors.teal), ), ); } } Center positions its child, Text displays words, TextStyle styles them — each a widget, composed by nesting. Layout widgets (like Row, Column, ...
Read more

Go Explained: Simple Code That Runs Fast

Introduction Go was built at Google for a specific frustration: large programs that were slow to build and hard to read. The answer was a language that is deliberately small — fewer features, but the right ones, done well. If you know one programming language already, Go will feel familiar within an hour. The interesting parts are not the syntax, but two ideas: goroutines and channels. Goroutines: cheap concurrency Most languages make running things at the same time feel heavy — threads, thread pools, and careful setup. A goroutine is Go's lightweight version: you start one by writing go in front of a function call. package main import ( "fmt" "time" ) func say(text string) { for i := 0; i < 3; i++ { fmt.Println(text) time.Sleep(100 * time.Millisecond) } } func main() { go say("hello") say("world") time.Sleep(500 * time.Millisecond) } The go say("hello") line does not wait — it st...
Read more