Nomenclatura y claridad
Mira este código:
|
const users = load_data(); for (users) |user| { process(user); } |
¿Qué tipo es users? ¿Qué tipo es user?
- ¿Un array de ids como números?
- ¿Un array de strings?
- ¿Un array de structs? etc.
No se puede saber sin buscar la declaración de load_data(). Sí, tu IDE es muy potente pero ¿y si no siempre lo tienes a mano? ¿Tanto dependes de ese IDE? ¿Y si estás aprendiendo con los playgrounds de los ejemplos de zenofzig.com? ¿Y si usas un editor muy espartano, libre, o debugueas un error a las 3 de la mañana, incluso a través de una sesión ssh?
Convención Zen of Zig
- Todos los nombres en minúscula y separados por guiones bajos (snake_case).
- CamelCase solo para nombres de structs o tipos definidos por el usuario.
- Las funciones no llevan prefijo.
- Usa nombres semánticos siempre que puedes.
- Todas las variables y constantes sí llevan prefijo, según su tipo o rol:
|
o_ |
Objeto / struct |
|
a_ |
Array o lista |
|
m_ |
Mapa o diccionario |
|
n_, f_ |
Número entero o float |
|
s_ |
Cadena de texto ([]u8) |
|
z_ |
Slice |
|
i_ |
Iterador |
|
t_ |
Tupla |
- Cuando no hay un nombre semántico, usa letras con prefijo: n_x, n_y, f_a
Ejemplos
Structs (CamelCase, sin prefijo):
|
const Player = struct { ... }; const HTTPClient = struct { ... }; |
Array de números:
|
for (a_scores) |n_score| { print("Puntuación: {}\n", .{n_score}); } |
Array de strings:
|
for (a_player_names) |s_name| { print("Nombre: {s}\n", .{s_name}); } |
Array de structs:
|
for (a_players) |o_player| { print("HP: {}\n", .{o_player.health}); } |
etc.
Loops anidados:
|
for (a_servers) |t_server| { for (t_server.a_databases) |t_db| { for (t_db.a_tables) |s_table| { //... } } } |
Ventajas
Búsquedas más precisas:
|
$ rg "a_items" # Solo arrays llamados items $ rg "n_count" # Solo contadores |
Code review sin IDE:
En git o en un log, el prefijo ya te dice qué es cada cosa. Cualquier editor simple vale.
Prevención de errores:
|
print("{s}\n", .{n_score}); // ← Error obvio: n_ no es string |
Onboarding rápido:
Un nuevo desarrollador entiende el código sin mirar las declaraciones previas.
¿Es obligatorio?
No. Es una herramienta de Zen of Zig. No es una regla del lenguaje Zig.
Puedes usarla si te sirve y cuándo te sirva.
¿Cuándo usarla?
- Código de aplicación,
- Equipos propios,
- Cuando aprendes,
- Si te apetece,
¿Cuándo no usarla?
- Si contribuyes al stdlib de Zig,
- Librerías open source de alto perfil,
- Proyectos con guias de estilo ya definidas
La realidad
La mayor parte de los programadores no escriben librerías públicas. Suelen crear:
- Scripts internos,
- Herramientas para su equipo,
- Aplicaciones de negocio,
- Prototipos
Para este tipo de actividades comunes, le puedes dar una oportunidad:
- Funciona también sin IDE.
- Se entiende mejor en las revisiones.
- Ayuda a detectar y prevenir errores.
- Reduce el tiempo de adaptación.
Los prefijos comunican la intención, no solo el tipo. Es solo una herramienta más.