Sobre los nombres

• ✅ Los nombres deben reflejar una intención
  • Deben indicarte por qué existen, qué hacen, y cómo se usarán.
  • Deben representar su contexto.
• ✅ Evita usar abreviaciones.
  • Utiliza hypotenuse en vez de hp.
• ✅ No escribas los nombres según su estructura de datos
  • Usa accounts en vez de accountList.
• ✅ No utilices nombres que no se evidencia una diferencia.
  • Encontrar la diferencia entre ControllerForEfficientHandlingOfStrings y ControllerForEfficientStorageOfStrings… 😫
• ✅ No nombres las variables sólo para satisfacer al compilador.
  • No utilices name1 porque name ya está ocupado.
• ✅ Evita usar palabras que generan ruido.
  • ProductData y ProductInfo parecieran significar lo mismo.
  • De la misma manera, palabras como a..., an..., the... también son palabras que hacen ruido, por ejemplo nombrar una variable product es suficiente, no necesitamos theProduct.
  • Palabras redundantes también son ruidosas, usa name en vez de nameString.
• ✅ Distingue los nombres para que el lector sepa cuál debe utilizar.
• ✅ Utiliza nombres fáciles de pronunciar. (Difícil cuando tu idioma nativo no es inglés)
• ✅ Utiliza nombres que puedas buscar.
  • Utiliza constantes en vez de valores en duro, WORK_DAYS_PER_WEEK = 5 en vez de 5.
• ✅ Incluir unidades de medida en las variables.
  • Usar expiryTimeInSeconds es mejor que expiryTime.
  • No es lo mismo que expiryTimeLocalDatedonde indicamos el objeto o la estructura de datos que lo contiene.
• ✅ El largo del nombre de una variable debe ser correspondido por su alcance. (scope)
  • Puedes tener una variable i dentro de un for loop, pero no i como variable de instancia.
• ✅ Clases y objetos deben tener sustantivos o frases nominales.
  • Evita palabras como Manager, Processor, Data o Info en el nombre de las clases, son muy genéricos y no entregan valor a lo que hace la clase.
  • Si el nombre de tu clase termina con er, or o utils, debieras considerar la responsabilidad de la clase, si no posees una buena justificación, piensa en un nuevo nombre.
  • El nombre de la clase no debe ser un verbo.
• ✅ Los métodos, en cambio, deben tener un verbo.
• ✅ Cuando los constructores sean sobrecargados, intenta usar métodos estáticos de factory con nombres que describan sus argumentos.
  • Complex fulcrumPoint = Complex.FromRealNumber(23.0) es mejor que Complex fulcrumPoint = new Complex(23.0).
• ✅ Elige un concepto abstracto de una palabra y reutilízalo.
  • Es confuso tener fetch, retrieve y get como métodos equivalentes de clases diferentes.
  • Si utilizarás retrieve para indicar el retorno de datos de un método en una clase, usa esa palabra en todas tus clases y no cambies por get o fetch a tu antojo.
• ✅ No agregues contexto adicional.
  • Para la aplicación “Gas Station Deluxe”, es una mala idea usar en cada clase el prefijo GSD.
  • Por ejemplo, AccountAddress en vez de GSDAccountAddress.
• ✅ Está correcto utilizar términos relacionados a la informática, ciencia de datos, términos matemáticos, nombre de patrones o nombres de algoritmos.
  • Usar siempre el dominio del problema para determinar nombres puede resultar complicado, por lo tanto, podemos usar los nombres del dominio de la solución según sea necesario.
• ✅ No agregues más contexto a un nombre del necesario.
  • Los nombres más cortos son mejores que los largos, siempre que sean claros.

Por último, si llevas más de 10 minutos eligiendo un nombre, explica a un compañero lo que hace tu clase y pídele que te sugiera un nombre que concentre la esencia de esta. Si tus compañeros al leer el nombre de la clase, coinciden en lo que suponen que hace, el nombre que elegiste es el correcto.