The shape of good code
Naming, locality, and the small disciplines that compound into a codebase you trust.
If you have read code for long enough you can feel when it is good before you understand it. There is a shape to it. A rhythm. The names line up. The flow goes left to right. The hard part lives in one place, not five.
I cannot fully define this shape. But I can describe the small disciplines that, in my experience, produce it.
Naming is a design tool, not a labeling tool
Most engineers treat names as labels — strings to point at things. Good engineers treat names as a forcing function. If you cannot name a thing cleanly, the abstraction is wrong. Rename it until you can. The new name will tell you whether to merge it, split it, or delete it.
Locality beats cleverness
The best code I have read keeps things close to where they are used. Not in a global helpers file. Not in a shared utilities folder seven levels up. Right there, next to the function that needs it, until there is a real reason to move it.
Premature sharing is one of the most expensive mistakes in a codebase. Two functions that look similar today are almost never the same function tomorrow.
Boring control flow
Top to bottom. Few branches. Early returns instead of nested ifs. The reader should be able to predict where the function is going by the third line. If they cannot, that is the bug — not in the logic, but in the shape.
Comments that explain why, not what
If a comment describes what the code is doing, the code probably needs renaming. Comments earn their keep when they explain why something exists — a constraint, an incident, a workaround. Those comments age well. The other kind rots fast.
Delete more than you add
The best PRs I have shipped were the ones with negative line counts. Removing dead code is not housekeeping; it is design. Every line that does not need to exist is a tax on every reader who comes after you.
Good code is not what is left after you add. It is what is left after you remove.
None of this is original. None of it is fancy. But practiced over months, on small decisions inside ordinary PRs, it is the difference between a codebase you have to fight and one you can trust.