Nomenclature and Clarity
Look at this code:
|
const users = load_data(); for (users) |user| { process(user); } |
What type is users? What type is user?
- An array of numeric IDs?
- An array of strings?
- An array of structs? etc.
You can’t tell without checking the declaration of load_data(). Sure, your IDE is very powerful -but what if you don’t always have it handy? Do you really depend that much on it? What if you’re learning through the playgrounds on zenofzig.com? What if you’re using a very minimal, open-source editor -or debugging a bug at 3 a.m., even through an ssh session?
Zen of Zig Convention
- All names in lowercase, separated by underscores (snake_case).
- CamelCase only for struct names or user-defined types.
- Functions have no prefix.
- Use semantic names whenever possible.
- All variables and constants use a prefix according to their type or role:
|
o_ |
object / struct |
|
a_, l_ |
array or list |
|
u_, e_ |
union, enum |
|
n_, f_ |
number |
|
s_ |
String ([]u8) |
|
z_ |
Slice |
|
i_ |
Iterator |
|
t_ |
Tuple |
- When there’s no meaningful name, use letters with a prefix: n_x, n_y, f_a.
Examples
Structs (CamelCase, no prefix):
|
const Player = struct { ... }; const HTTPClient = struct { ... }; |
Array of numbers:
|
for (a_scores) |n_score| { print("Score: {}\n", .{n_score}); } |
Array of strings:
|
for (a_player_names) |s_name| { print("Name: {s}\n", .{s_name}); } |
Array of structs:
|
for (a_players) |o_player| { print("HP: {}\n", .{o_player.health}); } |
etc.
Nested loops:
|
for (a_servers) |t_server| { for (t_server.a_databases) |t_db| { for (t_db.a_tables) |s_table| { //... } } } |
Advantages
More precise searches:
|
$ rg "a_items" # Only arrays named items $ rg "n_count" # Only counters |
Code review without an IDE:
In Git or in a log, the prefix already tells you what kind of thing it is. Any simple editor will do.
Error prevention:
|
print("{s}\n", .{n_score}); // ← Obvious error: n_ is not a string |
Fast onboarding:
A new developer can understand the code without having to check previous declarations.
Is it mandatory?
No. It’s a Zen of Zig tool - not a rule of the Zig language.
You can use it if and when it helps you.
When to use it?
- Application code
- Internal teams
- While learning
- When you feel like it
When not to use it?
- If you contribute to Zig’s stdlib
- High-profile open source libraries
- Projects with their own style guides
Reality check
Most programmers don’t write public libraries. They usually build:
- Internal scripts
- Team tools
- Business applications
- Prototypes
For these common activities, you might want to give it a try:
- Works even without an IDE
- Easier to review
- Helps spot and prevent bugs
- Reduces onboarding time
Prefixes communicate intent, not just type. It’s just one more tool for your toolbox.