Published on May 22, 2025

Martin's 10 Commandments of Rust Development

1. Thou Shalt Name With Intent

If a variable, struct, or function name doesn’t tell you what it is without a comment, rename it. Under no circumstances should a reader need to infer purpose from usage just because you got in a hurry.

2. Thou Shalt Document Every Damned Public Interface Like Someone’s Life Depends On It

You will write a doc comment (///) for every public struct, enum, and function. You will explain what it is, what it returns, and why it exists. Do not waste words. Do not skip this.

3. Thou Shalt Keep Scope Tight and Lifetimes Short

Declare variables only when you need them. Group logic that belongs together. If something hangs around longer than it should, destroy it with extreme prejudice.

4. Thou Shalt Derive What You Intend to Use, Nothing More

You will not simply slap on #[derive(...)] because it compiles. If the struct doesn’t need to be cloned, you do not derive Clone. If it's not user input, you do not derive Deserialize. Doing either will cost you a finger. Doing both will cost you a hand.

5. Thou Shalt Define Structs to Represent Real Concepts

You will never create structs as dumping grounds or magic runtime manipulators. Every struct will reflect a clear domain idea, not your convenience.

6. Thou Shalt Not Leave Dead Code Behind

Leave no placeholders. Leave no commented-out stubs. If something is "to be done," write a clear comment or leave a TODO. Otherwise, delete it. No exceptions. A TODO found in production code can and will result in public corporal punishment.

7. Thou Shalt Write Logs Like a Professional

Every log message shall be properly spell-checked, punctuated, informative, and readable by a human - this is not the 1980s. Say what happened. Say why it happened. Say what’s affected. Do not log your feelings. Do not log fluff.

8. Thou Shalt Be Explicit or Be Gone

You will not hide behavior behind clever indirection. Do not make other people chase down trait impls across dozens of files to figure out what’s happening. If it's important, make it visible.

9. Thou Shalt Use serde With Purpose, Not as a Crutch

Serialize metrics. Deserialize configuration. Do not pretend one type does both unless you have a strong reason, the scars to prove it, and are willing to testify under penalty of perjury.

10. Thou Shalt Make the Call Site Obvious

If calling a function reads like a riddle, rewrite the damned function. Boolean flags with hidden meanings are a fast-track to hell. 10-call method chains will ensure you are reincarnated as a dung beetle. The call site is the product — polish it.