Redis Creator's Code Philosophy: 10 Programming Principles from Antirez
May 09, 2025
Antirez is one programmer I respect a lot. He has a singular approach and style of programming that is both effective and efficient. I have been following him and his blogs for over an decade and its amazing how much you can learn watching him work. He is recently very active on 📺 Youtube and I would highly recommend watching him code and explain.
This tips are compiled from this blogs and his code on Github.
🧠 Write Code Like Salvatore Sanfilippo (antirez)
- Drawn from Salvatore Sanfilippo’s blog post on comments and the Redis source code.
- Each tip includes concrete actions and examples for you to follow.
1. Write Comments with a Purpose Class – Not a Reflex
Sanfilippo categorizes comments into nine types:
- ✅ Function
- ✅ Design
- ✅ Why
- ✅ Teacher
- ✅ Guide
- ✅ Checklist
- ❌ Trivial
- ❌ Debt
- ❌ Backup
✅ Action → Before committing code, mentally label every new comment. Keep it only if it fits in the first six.
2. Put a Design Comment at the Top of Every Non-Trivial File
He often opens a file with a short essay on how the piece works and why the chosen algorithm won.
✅ Action → Start new modules with a 10–20 line “README-inside-the-file” explaining the approach and discarded alternatives.
3. Use “Why Comments” to Freeze Hidden Reasoning
Lines that seem obvious in a diff often hide performance traps or protocol quirks. He documents those explicitly.
✅ Action → Anytime you touch a conditional or a magic constant, ask: “Will future-me remember why?” If not, write a Why comment.
4. Lower Cognitive Load with Guide Comments and Vertical Rhythm
Redis files often have simple headers like:
/* Free the query buffer */
These serve as section dividers to help skimming.
✅ Action → When a function exceeds ~40 lines, break it into visual blocks using one-line Guide comments.
5. Annotate Dynamic State In Situ
In Redis Lua helpers, he prints the Lua stack after every mutation—so readers never reconstruct it mentally.
✅ Action → For code that mutates state (stack, buffer, etc.), add live commentary after each transformation.
6. Keep the File/Build Surface Tiny
Kilo, his text editor, is <1000 LOC. Redis builds with one make. He avoids unnecessary complexity.
✅ Action →
- Favor plain C/C++ (or Go/Rust) and the standard library unless a third-party dependency buys a lot.
- Resist new build steps. If one is needed, explain it in the Design comment.
7. Model First, Code Later – “Code is Rewriting”
He compares coding to rewriting paragraphs in a novel—iterate until it reads well.
✅ Action → For greenfield components, plan to rewrite the first version at least once before merging.
8. Short, Single-Purpose Functions with CamelCase Names
Redis helpers like raxSeekGreatest or clientHasPendingReplies are clear, action-oriented, and do one thing.
✅ Action →
- Keep functions <100 LOC; if it grows, split it.
- Use
UpperCamelCasefor functions andlowerCamelCasefor variables.
9. Prefer Data-Structure-Driven Design
He crafts his own arrays (SDS), radix trees (Rax), and vectors instead of using generic containers.
✅ Action →
- Sketch your data structure on paper.
- If generic containers hide too much logic or performance, implement a slim, focused version and document it.
10. Use Comments as an Analysis Tool
He sees comments as a tool for rubber-duck debugging—if you can’t explain it clearly, it’s not ready.
✅ Action → Don’t commit until you can explain every non-trivial function in 2–3 sentences that feel obviously true.
🛠️ Putting It into Practice
- Start each file with a Design comment.
- Code small, single-purpose functions; separate logic using Guide comments.
- Review all comments: label them, trim the unnecessary ones, add Why or Teacher comments as needed.
- Refactor if a comment feels like an apology or excuse—make the code speak for itself.
- Commit with a message that reflects what changed and why, ideally mirroring your Why comments.
Follow this loop and your codebase will begin to read like Redis: direct, self-narrating, and friendly to the next engineer—quite possibly future-you.