Resumen de Clean Code - primera parte
Ultimamente he estado leyendo Clean Code, el ultimo libro del para mi gusto genial Robert Martin. El libro, como el titulo indica :P, esta orientado a proporcionar un conjunto de buenas practicas y recomendaciones para escribir mejor código, código más limpio y más legible.
El libro no se queda sólo en decir "hazlo así que si no esta mal" sino que presenta ejemplos bastante exahustivos de refactorización de código existente (por ejemplo refactorizado una clase del framework JUnit), digamos que el libro esta dividido en 3 partes:
- Capitulos teoricos, donde se exponen y justifican las buenas practicas recomendadas
- Capitulos practicos, donde se coje un código existente y se intenta mejorar aplicando las buenas practicas expuestas en los capitulos teoricos
- Un resumen de las buenas practicas en forma de "smells" y heuristicas simples. No esta mal como pequeña guia en plan recordatorio, siempre y cuando te hayas leido el resto del libro claro, por si solo no es demasiado útil.
Los capitulos teoricos van del 1 al 13, os cuento que es lo que más me ha gustado/llamado la atención en estos capitulos, el resto simplemente hay que leerselos, no tiene mucho sentido hacer un resumen de las partes practicas.
Capitulo 1 - Clean Code
Es un capitulo introductorio para justificar la intención del libro, recoje las opiniones de personalidades importantes de esto del desarrollo de software resaltando la importancia de escribir buen código, gente como Bjarne Stroustrup, Michael Feathers, Ron Jeffries o Grady Booch.
La idea principal del capitulo es que no hay nada más importante que escribir código de calidad para el exito de un proyecto, el autor utiliza muy a menudo la palabra "profesionalidad", hace mucho enfasis en dejar claro que un profesional responsable debe escribir siempre buen código, sean cuales sean las circunstancias, tiempos ajustados por ejemplo, ya que no hay nada que retrase más un proyecto que precisamente el mal código, tenemos que ser profesionales de verdad y hacer lo mejor que sepamos para garantizar la calidad de nuestro trabajo, en resumen, no ser chapuceros, que cada vez que hacemos una chapuza muere un gatito! :P
Me encanta de este capitulo que se de al código la importancia que tiene, algo obvio para cualquier desarrollador responsable, pero parece que no tan obvio para la gran mayoría del espectro de empresas que desarrollan software en esta nuestra querida españa :P (es el ambito que conozco, pero no creo que sea muy diferente en otras partes). Basta ya de adjetivos peyorativos como "picateclas", basta ya de menosprecioar la actividad más importante en el desarrollo de software: PROGRAMAR. Cuando esto se entienda, cuando las cosas se pongan en su lugar y se valore a los buenos profesionales que saben escribir clean code, entonces lo mismo empieza a cambiar un poquito esta industria.
Capitulo 2 - Meaningful Names
Pues si, un capitulo enterito para decir que escribamos nombres significativos para variables, funciones, clases etc,etc. Pero es que hay pocas cosas más determinantes para que un código sea legible como que tenga nombres en condiciones, pocas cosas más horribles que encontrase con variables tipo "aux1, aux2" o paquetes nombrados como "GUSU" en lugar de "my.company.servicios.gestion.usuarios" (ejemplo real :P )
Algunas recomendaciones que se ofrecen en el libro: usar verbos para nombrar los metodos y sustantivos para las clases, utilizar nombres pronunciables (esta me encanta, el código se LEE, si no puedo pronunciarlo me cuesta más esfuerzo leerlo), no usar notaciones tipo "los enteros empiezan por i, las cadenas por s" y chorradas similares (luego alguien cambia el tipo y se olvida de refactorizar el nombre... también tengo casos reales de esto :P ), no ahorrar caracteres poniendo abreviaturas, por ejemplo escribir "valEdadCli(...)" en lugar de "validarEdadDeCliente(...)".
Capitulo 3 - Functions
El capitulo trata de como escribir buenas funciones/metodos, la recomendación más importante del autor en este punto es sencilla: escribe funciones pequeñas. Si luego mirais las refactorizaciones de ejemplo en los capitulos practicos no encontrareis funciones de más de 10 o 20 lineas como muchisimo, totalmente de acuerdo con esta afirmación, sobre todo con lo facil que es refactorizar con cualquier IDE actual, no tiene disculpa escribir funciones de 100 o 200 lineas como se ven por ahí, no es muy profesional que digamos...
Otra recomendación importante es sobre el número de parametros que recibe una función, para el autor 3 parametros es el limite antes de empezar a pensar que algo estamos haciendo mal.
Capitulo 4 - Coments
Este capitulo personalmente me encanta, porque en el pasado me ha tocado discutir bastante por defender algunas de las cosas que precisamente defiende el tio bob en este libro, y ahora cuanto me toque discutir otra vez por lo menos tengo una buena referencia jeje.
Particularmente lo que más me gusta es una idea que creo que no todo el mundo tiene clara respecto a los comentarios, la gente considera a los comentarios como algo bueno, al código comentado como algo bueno: "mira que bien, esta todo comentado". El tio bob lo enfoca de otro modo, dice algo como "cada vez que escribes un comentario estas fallando como programador, tienes que escribir un comentario para clarificar algo porque no has sabido utilizar las herramientas que tienes (el lenguaje de programación) para dejar claras tus intenciones". Es decir, poner un comentario es el el ultimo recurso cuando despues de darle muchas vueltas no se te ocurre como clarificar una parte del código, en lugar de dedicar tiempo a escribir comentarios, dedicalo a arreglar tu código para que se entienda sin la necesidad de estos. No te olvides que estas usando un lenguaje de programación, aprende a usarlo correctamente y no ocultes tus carencias con este lenguaje añadiendo notitas al lado en otro lenguaje que dominas mejor y en el que si puedes expresarte (aunque bueno... esto no siempre es así tampoco que se ve cada comentario xd)
Otras recomendaciones son no escribir comentarios redundantes (tipica función "getEdad()" que tiene como comentario "devuelve la edad" ¿en serio?, que sorpresa!), otra que me gusta mucho: "el código comentado es una abominación, borralo!", odio y lo digo muy en serio, odio, el código comentado, si no lo vas a usar borralo que para volver atras tienes el sistema de control de versiones (y si no sabes usarlo, aprende, pero no enguarrines el código!). Una variante de esto ultimo en C/C++ muy divertida con la que me he encontrado alguna vez es usar bloques tipo "#ifdef 1/0", es muy divertido porque el editor como es lógico no muestra el contenido de un bloque "ifdef" que nunca se va a ejecutar de una forma especial, con lo que te puede llevar un buen rato descubrir que llevas media hora tratando de entender un trozo de código que jamas se ejecuta...
Con esto termino de momento que me esta quedando muy largo, en un proximo post termino de contar el resto de capitulos del libro.
Gracias por tus posts Alfredo. Es muy buena lectura. A ver si nos comentas algo del libro en algún podcast.
Saludos!
Enviado por German G. en septiembre 21, 2009 a las 09:14 PM GMT+01:00 #
+1 totalmente en los nombres. Recuerdo en un curso que quise llamar una función algo así calcularTotalPorCliente y el profesor me dijo que era un burro ... que eso había que abreviarlo.
+1 Para las funciones. Existe una medida que dice si existen más de 10 bloques de código en un método, el método debe ser troceado.
Y +1 con los comentarios. A mi al menos me molestan más que me arreglan cosas. De hecho cuando descargo un código que no es mio, lo primero que hago es quitar los comentarios y compactarlo para ver más líneas en la pantalla.
Y -1 lo del poner delante una n o una s. A mi me
ayudan a conocer la variable sin ver la definición. Sobre todo es muy util tratando colleciones al -> ArrayList, ht-> Hasttable, etc.
Saludos, Jorge
Enviado por JorgeRubira en septiembre 21, 2009 a las 10:31 PM GMT+01:00 #
Muy buen resumen Alfredo.
Lo de las funciones yo más que contar líneas verifico que hagan una sóla función y que se puedan visualizar completas en una pantalla. Lo que me da una media de 30 líneas por función.
Sobre los comentarios, coincido en que es mejor el que tu código sea autoexplicativo o ir un poco más a lo que Donald Knuth llama Literate programming (http://www.literateprogramming.com/). Sin embargo yo si suelo poner comentarios por el sencillo hecho de que eso me evitará llamadas un sábado a las 3 a.m. de un becario que pregunta qué coño hice en un código que escribí hace 1 año. No es por subestimar a los otros, pero no hay que olvidar que en el mundo de las consultoras otros serán los responsables de mantener el código que escribes hoy y hay que intentar facilitarles la vida además que no podemos estar seguros que siquiera sepán programar.
Enviado por Erick Camacho en septiembre 22, 2009 a las 12:19 AM GMT+01:00 #
jorge:
Lo de incluir en el nombre la información del tipo no me gusta por dos cosas sobre todo:
- Por que hace que los nombres de las variables no sean "pronunciables", me gusta el código que "se lee".
- Más importante, por que corres el riesgo de que la información codificada en el nombre termine desincronizandose con la definición del tipo. Por ejemplo, alguien que no conoce tu nomenclatura cambia un tipo y no cambia el nombre de la variable. (yo he visto cosas dantescas con esto :P)
Y luego con cualquier IDE llegas tienes la información del tipo a mano. Si es una función lo ves por que el "scope" es reducido (funciones pequeñas), y si es una propiedad tienes el outline o te vas a la definición en un click.
Enviado por Alfredo Casado en septiembre 22, 2009 a las 12:55 AM GMT+01:00 #
erik:
Lo malo de que lo coja un becario que no sabe programar es que te va a llamar igual, con comentario o sin comentario :P
Aunque ciertamente el código de mejor calidad es el que hace parecer simple lo complicado, el que no te da sorpresas cuando lo lees y todo parece obvio, en definitiva, el que entiende hasta un becario xd. Pero esto es más facil decirlo que hacerlo claro, y en ocasiones un comentario en el sitio preciso ayuda.
Lo importante es tener en la cabeza que es el ultimo recurso, antes de ponerlo replantearse si eso que estamos escribiendo no debería desprenderse naturalmente del propio código, si no sabemos hacerlo mejor o el lenguaje no lo permite, pues entonces no queda otra que ponerlo.
Enviado por Alfredo Casado en septiembre 22, 2009 a las 01:02 AM GMT+01:00 #
"el código de mejor calidad es el que hace parecer simple lo complicado"
+1 a eso colega! Código limpio si señor, de chapuzas y parafernalia innecesaria. Tan importante es una cosa como la otra.
Qué gran idea la de comentar el libro, precisamente es uno de los que tengo en mi pila mental de libros por leer! Ya no me acuerdo de la última vez que leí un libro no técnico...
De momento totalmente de acuerdo con las buenas prácticas que comentas. Lo del código comentado es realmente horrible, yo he llegado a encontrarme con métodos que tenían más código comentado que sin comentar. Y sobre los prefijos de tipo, me parece una práctica heredada de programación estructurada, cuando teniamos los datos por un lado y las funciones por otro. Yo los prefijos sólo los uso en caso de tener que hacer alguna transformación dentro de un método. Es decir, como mucho como variables de métodos, nunca como atributos!
Un saludo y gracias por tu tiempo.
Enviado por jcesarperez en septiembre 22, 2009 a las 08:00 AM GMT+01:00 #
Notación húngara se le llamaba a lo de los prefijos en MFC (creo que lo ideó un programador húngaro @ M$). Y tenían su sentido cuando los IDE's no pasaban de ser editores con coloreado... Desde luego ahora no.
Un punto que me parece que todos os estáis saltando... código en castellano? Ni de coña. ¿Como puede ser legible algo que mezcla idiomas? 'if(contrasenia.equals("admin"))' es de lo más feo que he visto, pero no parece haber polémica sobre eso...
La última ocurrencia en ese sentido es la de un pavo que hizo un clon de menéame y al tío no se le ocurrió mejor idea que usar EUSKERA! Pensádlo la próxima vez que penséis que algo está más claro en la lengua materna ;-)
De hecho yo diría que un código no escrito en inglés pierde hasta valor económico, si algún día la empresa es comprada...
Salu2
Enviado por Ibon Urrutia en septiembre 24, 2009 a las 08:09 AM GMT+01:00 #
Por cierto, el libro es altamente recomendable, aunque puedas no estar de acuerdo con ciertas prácticas. En el grupo en el que estoy se lo recomiendo a todos los programadores, sobre todo cuando alguien me pregunta que reglas de programación debemos seguir.
Salu2
Enviado por Ibon Urrutia en septiembre 24, 2009 a las 08:11 AM GMT+01:00 #
Lo del idioma si que es verdad que es un tema caliente que suele ser evitado. Yo he llegado a encontrarme tablas con sus nombres en catalán! Trabajo en Murcia...
Pero visto el nivel de inglés en España, no me atrevo, aunque me gustaría, a forzar a escribir en inglés. Examinando mi código me he dado cuenta de que suelo poner la mayoría de nombres de atributos en español pero los métodos todos en inglés. ¿Cómo hacéis vosotros?
Enviado por jcesarperez en septiembre 24, 2009 a las 08:27 AM GMT+01:00 #
Eberithing in English, mi friend :-D
En el javadoc suelo ser más flexible, y suelo dejarlo en castellano (si hace falta javadoc, es por dejar algo claro, y mejor que les quede claro en castellano), asi como las trazas de Log. Pero en atributos y métodos, todo inglés.
Salu2
Enviado por Ibon Urrutia en septiembre 24, 2009 a las 01:02 PM GMT+01:00 #