Falta de calidad en el codigo La deuda tecnica se paga con Refactorización, es imprescindible contar con pruebas automaticas.
- Nombre de variables pronunciables y expresivos (en ingles, camelCase)
- Arreglos en plural
// malo const fruit = ['manzana', 'pera', 'naranja'] // regular const fruitLits = ['manzana', 'pera', 'naranja'] // mejor const fruits = ['manzana', 'pera', 'naranja']
- Boleanos, usar:
is, has
, evitar negación. Ej:isEmpty, hasValues, isActive
- Numeros, utilizar
of
Ej:numberOfFruits, maxFruits, minFruits, totalOfFruits
- Funciones deben ser descriptivas
- Usar UpperCamelCase
- Preguntas para determinar el nombre correcto:
- ¿Que excatamente ahce la case?
- ¿Como exactamente esta clase realiza cierta tarea?
- ¿Hay algo especifico sobre su ubicacion?
- Propiedades estaticas primero, propiedades privadas ultimo.
- Constructores estaticos
- Constructor
- Metodos estaticos
- Metodos privados
- Resto de metodos ordenados de mayor a menor por importancia
- Getters y setters al final
- Debe hacer exactamente lo que su nombre indica
- Limitar hasta 3 parametros
- Ordenar parametros en forma ascendente
- Tamaño reducido
- Simplicidad, hacer solo una cosa
- Menos de 20 lineas de codigo
- Evitar el uso del "else"
- Priorizar el uso de la condicional ternaria
- Evitar tener muchas identaciones
Tip 1: Para evitar el uso de if/else, utilizar: arrays, includes
- Hasta 80 caracteres por linea
- Evitar la triple condicional, utilizar arrays
- Evitar swicth, utilizar objetos literales
- Evitar usar comenrarios, el codigo debe hablar por si mismos (autoexplicativo) utilizando buenos nombres de variables, funciones,etc.
Si quieres ser un programador productivo esfuérzate en escribir código legible
- Evita tener duplicidad de código
- Simplifica las pruebas
- Ayuda a centralizar los procesos
- Aplicar DRY, usualmente lleva a refactorizar
Priorizar la composición en lugar de herencia
- S – Single Responsibility Principle (SRP) : Responsabilidad unica
- O – Open/Closed Principle (OCP): Abierto/Cerrado
- L – Liskov Substitution Principle (LSP)
- I – Interface Segregation Principle (ISP)
- D – Dependency Inversion Principle (DIP)
- Patron singleton
- Alto acomplamiento
- Codigo no probable
- Optimizaciones prematuras
- Nombres pocos descriptivos: Ser muy especifico o demasiado generico
- Duplicidad de codigo: No aplicar el principo DRY
Acoplamiento: Dependencia entre clases o modulos entre si
Lo ideal es tener bajo acoplamiento y alta cohesion