1) Meaningful Names
Usar nombre relevantes y de intención. No usar una variable llamada «d» y si «fileAgeInDays»
Evitar usar nombres que no den información.
No usar como nombre el tipo de variable que es. No usar «accoundList pero si accounds».
Evitar la desinformación.
No usar nombres largos que solo se diferencien en una palabra. No usar el mismo nombre para cosas que signifiquen lo mismo.
No usar nombres que sean impronunciables. Ej: genymdhns.
Usar nombres que sean fáciles de buscar.
No usar prefijos.
Si tenemos interfaces e implementaciones, es preferible poner «Impl» a la implementación que no «I» a la interface.
Los nombres de clase tiene que ser nombres. No deben ser un verbo.
Los nombres de los métodos tienen que ser verbos.
No usar nombres graciosos.
Una palabra, un concepto.
Usar nombres por contexto. Ej: «State» de dirección y estado de la variable.
2) Functions
Las funciones tienen que tener un tamaño reducido. Tiene que ser lo suficientemente grande que se pueda entender.
Las funciones solo deben hacer una cosa. Deben hacerlo bien y deben ser lo único que hagan.
Para validar que solo hace una cosa, se puede escribir usando un párrafo con TO.
Las funciones tienen que contener elementos que estén en el mismo grado de abstracción. No mezclar niveles de abstracción.
Poner las funciones de abajo a arriva.
No usar un switch. Usar una factoría de objetos y solo usar el switch para crear estos objetos. Un switch viola el principio de responsabilidad único y el de abierto cerrado.
Invierta tiempo en elegir un nombre y cámbielo las veces que sea necesario. Tienen que ser descriptivos.
Es mejor no usar parámetros para llamar a las funciones. Cuantos más argumentos, más difícil es de testear el código. Hay que disminuir el número de argumentos, por ejemplo, añadiéndolo a un objeto.
Si añadimos contexto a los nombres, podemos mejorar su lectura. Ej: write(name), es mejor writeField(name).
No usar parámetro boolean que signifiquen comportamiento.
Los argumentos de entrada es preferible que no sean de salida.
No usar código de errores, es mejor usar excepciones. Al usar clave de errores, se acopla el código a estos errores ya existentes, no se añaden códigos nuevos, se reutilizan los antiguos… con las excepciones se pueden añadir nuevas sin problema.
Los bloques try y catch es mejor extraer su cuerpo en funciones individuales.
Solo tener un punto de entrada y un punto de salida. Solo tener un return dentro de la función.
Una buena forma de trabajo es:
- Estructurar las ideas
- Crear funciones, no importan que sean extensas o complicadas, con sangrados y bucles anidados. Los nombres son arbitrarios, la lista de argumentos son extensas, código duplicado… pero con una batería de pruebas que abarcan todas las líneas
- Retocar el código, dividirlo en funciones, cambiar nombres, eliminar duplicados.
- Al final, se consigue que se cumplan las reglas descritas.
Escribir el código es como contar una historia.
Las funciones tienen que ser breves, con nombres correctos y bien organizadas.
