Estilo de código
Plantilla de ejemplo. Ajusta estas reglas a las necesidades reales de tu equipo.
Principios generales
- Consistencia sobre preferencia personal. Si una regla está definida, se sigue aunque a alguien le guste otra forma.
- Legibilidad primero. El código se lee muchas más veces de las que se escribe.
- Automatiza lo automatizable. Formateo y linting no deberían ser temas de revisión manual.
Herramientas
| Propósito | Herramienta | Configuración |
|---|---|---|
| Formateo | Prettier | .prettierrc |
| Linting | ESLint | eslint.config.js |
| Tipado | TypeScript (strict) | tsconfig.json |
Ningún PR se aprueba si falla el linter o el chequeo de tipos. Estos controles corren en CI.
Reglas de TypeScript
- Activa
strict: trueentsconfig.json. - Evita
any; usaunknowny reduce el tipo cuando sea necesario. - Prefiere
typepara uniones yinterfacepara contratos de objetos extensibles.
// ✅ Bien: tipo explícito y descriptivo
type EstadoPago = 'pendiente' | 'aprobado' | 'rechazado'
function procesarPago(estado: EstadoPago): void {
// ...
}
// ❌ Evitar
function procesar(estado: any) {
// ...
}Comentarios
- Comenta el porqué, no el qué. El código ya dice qué hace.
- Borra el código muerto en lugar de comentarlo: para eso está el control de versiones.
Checklist antes de abrir un PR
- El código está formateado (Prettier).
- No hay errores de linting ni de tipos.
- Los nombres siguen la guía de nomenclatura.
- Hay pruebas para la lógica nueva relevante.
Last updated on