Beautiful Is Better Than Ugly

“Beautiful is better than ugly” is the first line of PEP 20, and it’s the one engineers are quickest to wave off as a matter of taste. I read it as a maintenance rule. Beautiful code is easy to read, and code that’s easy to read is easy to change.

The Zen got it right

The Zen of Python is nineteen short lines from Tim Peters, and you can print it from any Python prompt with import this. Beauty comes first. Much of what follows reads like a definition of that first line: explicit over implicit, simple over complex, flat over nested, sparse over dense, and readability counts. Python wrote these down, but none of them are specific to Python.

There’s a joke hidden in the module, too. The source of this.py stores the Zen as a ROT13-encoded string and decodes it with a hand-built lookup table. The code that prints “Beautiful is better than ugly” is about as ugly as a short Python file gets. It’s hard not to read that as a wink.

What ugly costs

Ugly code works, which is why it survives. It passes the tests, it ships, and the bill arrives later, paid by whoever reads it next.

Here’s a function that does its job:

python def chk(d): r = [] for k in d.keys(): if d[k]["status"] == "active": if d[k]["days_overdue"] > 30: r.append(k) return r

And the same function after ten minutes of care:

```python OVERDUE_THRESHOLD_DAYS = 30

def overdue_active_accounts(accounts): return [ account_id for account_id, account in accounts.items() if account[“status”] == “active” and account[“days_overdue”] > OVERDUE_THRESHOLD_DAYS ] ```

Same behavior. The second version tells you what it’s for before you read the body, names the magic number, and drops a level of nesting. Nobody will ever file a bug against the first version. People will just read it slower, misread it now and then, and work around it rather than change it.

Beautiful usually means boring

When engineers argue about beautiful code, someone eventually holds up a clever one-liner: a nested comprehension with a walrus operator and a conditional expression tucked inside. It can be satisfying to write. It’s rarely pleasant to read, and dense code is good at hiding bugs.

The beauty PEP 20 means has more in common with good typography. Names are consistent, and the shape of the code matches the shape of the problem: a lookup table where the logic is a lookup, a pipeline where data flows in one direction, an early return where there’s a precondition. You mostly notice it by not noticing anything. The code reads at about the speed you read prose.

Let the tools handle the surface

Some ugliness is mechanical: indentation, quote style, line length, import order. Arguing about it in code review is a waste of everyone’s afternoon. Python has Black and Ruff, Go ships gofmt, JavaScript has Prettier, Ruby has RuboCop. Pick one, run it on save and in CI, and stop discussing it.

That frees review for the ugliness a formatter can’t see. A function named process that does four things. A boolean parameter that quietly flips the meaning of the whole call. Those are judgment calls, and they’re where a reviewer’s attention is worth spending.

It matters more as more code comes from a model. Generated code tends to be correct and long-winded, with vague names and defensive checks for cases that can’t happen. A formatter won’t catch any of that. Code quality still matters when a model writes it, and “would I call this beautiful?” is a fair question to ask in review.

Beautiful comes first in the Zen, and much of the rest explains how to get there. Write the version of the code you’d want to inherit.