-
Notifications
You must be signed in to change notification settings - Fork 1
cleanCode
El código debe leerse de arriba hacia abajo.
Evitar palabras como, Manager, Processor, Data o Info. El nombre de una clase no debe ser un verbo.
Deben tener nombres de verbos, como postPayment, deletePage o save. Los métodos de acceso, modificación y predicados, deben tener los prefijos (.get, .set, e .is)
Opta por la claridad, antes que el entretenimiento. es mas correcto usar abort(), que eatMyShorts().
Usa la misma palabra por concepto y mantenla.
Evita el juego de palabras,no uses la misma palabra con fines distintos.
Las funciones sólo deben hacer una cosa.
No deben tener más de tres argumentos y estos deben ser de forma puntual y muy justificada.
Pasar un argumento de indicador, como un booleano a una función es una práctica desaconsejable. Indica automáticamente que la función hace más de una cosa.
Las funciones que llamen a otras funciones, deben estar lo más juntas posible verticalmente hablando.
El único comentario bueno, es aquel que no se tiene que escribir. El código tiene que ser lo suficientemente claro y descriptivo para no necesitar comentarios. Los comentarios NO compensan un código confuso o desorganizado.
No comentar el código. Elimina el código, para guardar están los sistemas de control (GIT).
Estos comentarios son usados para indicar algo, que se debería haber echo y que no se ha producido.
Exceptuando los comentarios, legales y estándares corporativos, incluso estos mismos pueden hacer referencia a una licencia estándar o a otro documento externo.
Afinidad Algunos conceptos deben estar cerca unos de otros, como las funciones que son llamadas por otras o un grupo de funciones que realicen una función similar. Las funciones que tengan una elevada afinidad conceptual, deben estar cerca, independientemente si se llaman dentro de otras funciones.
Orden vertical Las ordenes que son invocadas deberán aparecer debajo de las ordenes que invocan, como ocurre en una noticia, los conceptos más importantes, los esperamos arriba.
Por norma general, se prefieren códigos cortos de esta manera estableceremos un límite de no más de 120 caracteres.
Densidad horizontal Los espacios en blanco se utilizan para marcar argumentos, como operacionales, pero no paréntesis o nombres de función.
Estilo de sangrado Aunque estemos tentados a no usar un sangrado en instrucciones como if sencillos, siempre se debe utilizar para facilitar la lectura.
Cuando formamos parte de un equipo es necesario, establecer un formato de escritura común, para realizar una escritura coherente en el programa.
El Código por procedimientos facilita la inclusión de nuevas funciones sin modificar la estructura de datos El código orientado a objetos facilita la inclusión de nuevas clases sin cambiar las funciones
Por lo tanto en sistemas dónde tengamos que añadir nuevos tipos de datos, usaremos la programación orientada a objetos. En el sistema dónde tengamos que añadir nuevas funciones en lugar de tipos de datos usaremos código por procedimientos.
Un módulo no debe conocer, los entresijos de los objetos que manipula. Por lo tanto los objetos ocultan sus datos y muestran sus operaciones.
Las estructuras de datos tienen variables públicas y funciones Privadas. Los objetos, tienen variables privadas y funciones Públicas.
A la hora de realizar una excepción hay que asegurarse de que estas muestren correctamente el contexto y el error y hay que guardar los registros en la aplicación.
al utilizar null generamos una interrupción en el código, lo que propensa a más errores, es más sencillo generar listas vacías que permitan manejar los errores in verse interrumpido el programa.
En ocasiones nos vemos tentados a utilizar comprobaciones que rompen con el sentido de la lectura de nuestro código en este caso es mejor preparar un método más inclusivo que nos permita leer el código sin interrupciones.