mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-11 10:43:10 +08:00
ac0f11c640
Adds a complete Spanish translation of the ECC documentation under docs/es/, mirroring the Turkish (docs/tr/) translation in scope. 141 files covering agents, commands, rules, skills, contexts, examples, and core docs. Updates root README.md with the Spanish language link. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
91 lines
2.9 KiB
Markdown
91 lines
2.9 KiB
Markdown
# Estilo de Código
|
|
|
|
## Inmutabilidad (CRÍTICO)
|
|
|
|
SIEMPRE crear objetos nuevos, NUNCA mutar los existentes:
|
|
|
|
```
|
|
// Pseudocódigo
|
|
INCORRECTO: modify(original, campo, valor) → modifica original in-place
|
|
CORRECTO: update(original, campo, valor) → retorna nueva copia con el cambio
|
|
```
|
|
|
|
Justificación: Los datos inmutables previenen efectos secundarios ocultos, facilitan la depuración y permiten concurrencia segura.
|
|
|
|
## Principios Fundamentales
|
|
|
|
### KISS (Keep It Simple)
|
|
|
|
- Preferir la solución más simple que realmente funcione
|
|
- Evitar optimización prematura
|
|
- Optimizar para claridad, no para ingeniosidad
|
|
|
|
### DRY (Don't Repeat Yourself)
|
|
|
|
- Extraer lógica repetida en funciones o utilidades compartidas
|
|
- Evitar la deriva por copiar y pegar implementaciones
|
|
- Introducir abstracciones cuando la repetición es real, no especulativa
|
|
|
|
### YAGNI (You Aren't Gonna Need It)
|
|
|
|
- No construir features o abstracciones antes de que sean necesarias
|
|
- Evitar generalidad especulativa
|
|
- Comenzar simple, luego refactorizar cuando la presión es real
|
|
|
|
## Organización de Archivos
|
|
|
|
MUCHOS ARCHIVOS PEQUEÑOS > POCOS ARCHIVOS GRANDES:
|
|
- Alta cohesión, bajo acoplamiento
|
|
- 200-400 líneas típico, 800 máximo
|
|
- Extraer utilidades de módulos grandes
|
|
- Organizar por feature/dominio, no por tipo
|
|
|
|
## Manejo de Errores
|
|
|
|
SIEMPRE manejar errores de forma exhaustiva:
|
|
- Manejar errores explícitamente en cada nivel
|
|
- Proporcionar mensajes de error amigables en código orientado a la UI
|
|
- Registrar contexto detallado del error en el lado del servidor
|
|
- Nunca silenciar errores
|
|
|
|
## Validación de Entrada
|
|
|
|
SIEMPRE validar en los límites del sistema:
|
|
- Validar toda la entrada del usuario antes de procesarla
|
|
- Usar validación basada en esquemas donde esté disponible
|
|
- Fallar rápido con mensajes de error claros
|
|
- Nunca confiar en datos externos (respuestas de API, entrada de usuario, contenido de archivos)
|
|
|
|
## Convenciones de Nomenclatura
|
|
|
|
- Variables y funciones: `camelCase` con nombres descriptivos
|
|
- Booleanos: preferir prefijos `is`, `has`, `should`, o `can`
|
|
- Interfaces, tipos y componentes: `PascalCase`
|
|
- Constantes: `UPPER_SNAKE_CASE`
|
|
- Custom hooks: `camelCase` con prefijo `use`
|
|
|
|
## Code Smells a Evitar
|
|
|
|
### Anidamiento Profundo
|
|
|
|
Preferir retornos anticipados sobre condicionales anidados cuando la lógica empieza a acumularse.
|
|
|
|
### Números Mágicos
|
|
|
|
Usar constantes nombradas para umbrales, retrasos y límites significativos.
|
|
|
|
### Funciones Largas
|
|
|
|
Dividir funciones grandes en piezas enfocadas con responsabilidades claras.
|
|
|
|
## Lista de Verificación de Calidad de Código
|
|
|
|
Antes de marcar el trabajo como completo:
|
|
- [ ] El código es legible y bien nombrado
|
|
- [ ] Las funciones son pequeñas (<50 líneas)
|
|
- [ ] Los archivos están enfocados (<800 líneas)
|
|
- [ ] Sin anidamiento profundo (>4 niveles)
|
|
- [ ] Manejo de errores apropiado
|
|
- [ ] Sin valores hardcodeados (usar constantes o configuración)
|
|
- [ ] Sin mutación (patrones inmutables usados)
|