Libros

Poner nombres correctos al picar código

Aquí dejo unos pequeños tips de cosas a tener en cuenta a la hora de poner buenos nombres a clases, variables, métodos, etc.. cuando estamos desarrollando.

  1. Técnicas para elegir nombres
  • Pronunciables.
  • En inglés.
  • Tan largos como sea necesario.
  • Índices de los bucles i,j,k.
  • Evitar reflejar información sobre los tipos en el nombre.
  • Interface de una sola clase, no por norma, a veces sí, a veces no.
  • El nombre de una variable, entender para qué se usa.
  • No añadir información técnica al nombre.
  • No utilizar sufijos.
  • ¿Para qué es? buena pregunta para crear un buen nombre.
  • Evita prefijos, sufijos y cualquier otra palabra con información sobre la naturaleza técnica de la abstracción.
  • Nombres concretos: pensar si un nombre es aplicable a muchos elementos a la vez, en cuyo caso quizás debamos descartarlo.
  • Cada línea de código sea lo más parecida a una frase con sentido en lenguaje natural.
  • Utilizar prefijos de tipo pregunta, para expresiones o variables tipo boolean: is, has, does, are, contains, will, should… Incluso a veces se utilizan las negaciones isNot, doesnt, hasnt…,
  • And, Or, no se utilizan, si denota dos comportamientos huele a tener que ser refactirizado.
  • Prefijo is para las expresiones booleanas
  • Los sinónimos y las traducciones son innecesarias, introducen una indirección que dificulta la lectura.
  • El nombre de un método debe apoyarse en el contexto proporcionado por el nombre de su clase, así como por los nombres de sus argumentos y sus tipos.
  • Los tipos específicos atraen nombres de variables acordes a ellos, además de comportamiento.
  • Cuantos menos parámetros tenga un método, más probabilidad hay de que su implementación quede simple y de que tenga una única responsabilidad.
  • Si un método no devuelve nada, es porque va a alterar el sistema, ya sea modificando los argumentos, el estado interno de la clase, la base de datos, la cola de mensajes… por tanto es recomendable poner nombres con un tono imperativo.
  • Distinguir sustantivos, verbos y adjetivos: usamos sustantivos para nombres de clase/módulo/paquete y verbos para nombres de método/función.
  • Practicar TDD ayuda a nombrar
  • Mantener una cierta homogeneidad en la forma de implementar, suele producir mejores resultados que programar de manera arbitraria cada bloque de código.
  • Los verbos responden a la pregunta de «¿qué hace?», mientras que los sustantivos responden a la pregunta de ¿qué es?, y a veces también a la pregunta de ¿para qué es?

Fuente: Libro Código Sostenible de Carlos Blé Jurado.

Adelantando lecturas

Agradezco la comunicación fluida con Yazmina y Fran. Recibí de ellos pistas de lo que podía ir mirando antes de empezar las practicas en Lean Mind. Info de TDD, código sostenible, Testing sostenible, etc… Es genial que se preocupen por ti, que muestren interés por lo que haces, y eso es lo que siento, arropo. Voy a seguir leyendo el libro «Diseño ágil con TDD» de Carlos Blé que ya tenía empezado y «Código limpio» de Robert Cecil Martin, este libro lo descubrí gracias a Adrián Ferrera, en un video de YouTube en el canal de «Lean Mind» en el que hablaba de arquitectura de software. Cuando no me encuentre con fuerzas para asimilar conocimientos de programación, agarraré «Comunicación no violenta, un lenguaje de vida» de Marshall B. Roserberg. Mucha información pero a poquitos, seguro que me vendran bien.

Código sostenible

Después de terminar de leer el libro estoy seguro, seguro de haber recibido conocimiento por muy poco. Es un texto lleno de enseñanzas, reflexiones, buenos hábitos y grandes consejos, algo que no es fácil tener tan al alcance de la mano. Ejemplos fáciles de entender que ayudan a la comprensión, a interiorizar mejor los conceptos y animarse a picar código. Reconozco que necesito leerlo con aún más detenimiento, hay momentos que por lo que sea no estás del todo centrado, no asimilas igual los conceptos y es mejor volver a releer en otro momento para asimilar conceptos y experiencias de una manera más eficiente. También hay partes un poco más densas, otras más ligeras, algunas que domino mejor y me han resultado más fáciles de entender pero otras he ido tomando notas para volver a ellas más adelante, en otro momento con más tranquilidad. Es un texto maravilloso que me ha servido para lanzarme a la piscina con la programación. Se que es un camino muy largo, que esto solo es el principio, pero me encanta haber empezado mi camino de esta manera, acompañado de Código sostenible. Espero que me acompañe en este camino durante mucho tiempo y me ayude a superar muchos obstáculos. Gracias a Carlos por este libro y por sus palabras que me animaron a dar el paso a picar código.