There are hundreds of coding best practices out there. Books like Clean Code offer deep insights. Big tech companies publish detailed style guides. And countless articles explore every nuance of naming, formatting, testing, and structure.
But in day-to-day work—especially in fast-moving teams—we don’t always need more rules. We need clarity. We need alignment. We need a shared mindset.
That’s why I like working with manifestos. They help create a common language and set a north star for collaboration. Something that’s easy to remember, easy to teach, and easy to use in real conversations about code.
You can’t tell a new teammate: «Read this 200-page book to understand how we write code here.»
But you can give them this.
The Coding Manifesto
1. Readability comes first, always
- Code is read more than it’s written.
- Write for humans, not machines.
- Choose clarity over cleverness.
2. Tests are first-class citizens
- Every feature includes meaningful, reliable tests.
- Tests document intent and catch regressions.
- They deserve the same care as production code.
3. Functions should be small and focused
- Each function does one thing well.
- Operate at a single level of abstraction.
- Extract helpers instead of mixing concerns.
4. Prioritize explicitness and clarity
- Prefer explicit behavior.
- Name things to reveal intent.
- Keep key decisions close to the code.
5. Naming is part of design
- Good naming is not cosmetic; it’s a design tool.
- Names should be descriptive, not cryptic.
- Follow consistent naming patterns.
6. Minimize dependencies; prefer the standard library
- Add dependencies only with clear justification.
- Don’t import a library to sort a slice.
- Every dependency adds maintenance cost.
7. Handle errors explicitly
- Catch errors where they can be meaningfully handled.
- Never ignore them silently.
- If skipped, document why.
8. Make side effects obvious
- Reflect side effects in function names or signatures.
- Avoid hidden behavior (like writing to a DB or sending emails).
9. Prefer explicit dependencies
- Pass dependencies directly.
- Avoid hidden access via globals or magic containers.
10. Consistency beats individual preference
- Follow team conventions.
- Avoid endless style debates.
- Consistent code is easier to navigate, maintain, and onboard.
This isn’t a checklist. It’s a mindset.
In environments where people come and go, projects evolve, and speed matters, a shared philosophy is often more useful than rules.
This manifesto isn’t the only way to work well. But it’s a way I’ve found useful—one that teams can rally around and evolve over time.
Feel free to use it, adapt it, or fork it.
And if you or your team have your own principles you love, I’d love to hear them.
Walking the Stack 