06-22-2026, 12:38 PM
Clean code is one of those topics everyone has opinions on but nobody fully agrees on. Some people swear by Uncle Bob, others think a lot of it is overengineered nonsense for solo projects.
Here are the principles I genuinely apply day-to-day:
Names over comments. If you need a comment to explain what a variable or function does, the name is wrong. getUsersWithExpiredSubscriptions() beats getUsers() with a three-line comment every time.
Functions do one thing. If you have to use "and" to describe what a function does, split it. This also makes unit testing trivial.
Short functions, not long ones. I aim for under 20 lines. If it's longer I ask what I can extract.
Avoid double negatives. if (!isNotAdmin) is a brain teaser. if (isAdmin) isn't.
Consistent formatting is non-negotiable. Pick a linter, commit the config, and never argue about tabs vs spaces again.
What are the rules you actually follow? And are there any "best practices" you think are cargo cult nonsense in the real world?
Here are the principles I genuinely apply day-to-day:
Names over comments. If you need a comment to explain what a variable or function does, the name is wrong. getUsersWithExpiredSubscriptions() beats getUsers() with a three-line comment every time.
Functions do one thing. If you have to use "and" to describe what a function does, split it. This also makes unit testing trivial.
Short functions, not long ones. I aim for under 20 lines. If it's longer I ask what I can extract.
Avoid double negatives. if (!isNotAdmin) is a brain teaser. if (isAdmin) isn't.
Consistent formatting is non-negotiable. Pick a linter, commit the config, and never argue about tabs vs spaces again.
What are the rules you actually follow? And are there any "best practices" you think are cargo cult nonsense in the real world?
