Comentar tu código es como limpiar el cuarto de baño. Nunca quieres hacerlo, pero resulta en una experiencia más agradable para ti y para todos tus invitados.

~ Ryan Campbell

Las dos formas más comunes de proporcionar una dependencia a una función son, por un lado, los parámetros de la función:

function insertarItem($db, $item) {
	// Haz algo
	// ...

	$db->insertar($item);

	// Haz más algo
	// ...
}

y por otra parte, cualquier tipo de mecanismo de acceso global con el que contemos en el lenguaje (variables globales, patrón Singleton, etc). En este ejemplo en PHP utilizamos la palabra clave global para crear una variable local con una referencia a la variable global.

function insertarItem($item) {
	// Haz algo
	// ...

	global $db;
	$db->insertar($item);

	// Haz más algo
	// ...
}

En principio podría parecer que no hay mucha diferencia entre ambos ejemplos. Nada más lejos de la realidad.

El primer problema con el que nos encontramos es que las variables globales ocultan las dependencias, y transportan la información de un lado a otro por arte de magia. Imagina que quieres utilizar la función insertarItem dentro de un año. Podrías pensar que puedes usarla de esta forma:

insertarItem($item);

cuando, de hecho, la función puede estar esperando que hagas esto:

$GLOBALS['db'] = new Db('localhost', 'mibbdd', 'usuario', 'pass');
$_SESSION['permisos'] = new Usuario()-<permisos();
insertarItem($item);

¿Cómo podrías saberlo sin tener que leer todo el código?

Otro problema es que es terriblemente difícil seguir sus cambios. Es posible que en algún momento crees otra variable global con el mismo nombre, y termines sobre escribiendo su valor sin percatarte, lo cuál generaría errores de lo más esotérico y de lo más difícil de depurar.

Las variables globales son malvadas por, al menos, 6 razones relacionadas:

1. El código es más difícil de entender
2. El código es más difícil de depurar
3. El código es más difícil de testear
4. El código es más difícil de mantener
5. El código es más difícil de reutilizar
6. Las variables globales matan gatitos

A pesar de todo puede tentarte usar variables globales para no tener que pasar el objeto $db a todas y cada una de las funciones que puedan necesitarlo, por ejemplo, y todas las funciones que llamen a funciones que puedan necesitarlo. En ese caso, en lugar de una colección de funciones con usos relacionados, puedes utilizar clases, y pasar la dependencia al objeto utilizando el constructor. Otras opciones son el uso de los patrones Abstract Factory, Service Locator o, mucho mejor, la inyección de dependencias (Dependency Injection, también llamado Inversion of Control).

Ojo, porque el patrón Singleton NO es una solución adecuada a este problema. Sí, es uno de los patrones explicados en Design patterns: elements of reusable object-oriented software, uno de los 10 libros míticos que todo programador debería leer, pero se suele abusar de él utilizándolo simplemente como una especie de variable global glorificada. Así las cosas, existen multitud de artículos que desaconsejan su utilización, e incluso Google desarrolló en su día un pequeño script para detectar el uso de singletons y poder eliminarlos.

Clean Code se estructura alrededor de una idea básica: la de que el buen código es resultado, ante todo, de prestar atención a los pequeños detalles. Muchas veces estamos tan centrados en la arquitectura, o en acumular patrones y principios que no sabemos aplicar correctamente, que no damos la importancia que se merece a otros detalles que pueden parecer menores, pero que tienen igual o mayor importancia. No olvidemos que antes de correr, se ha de aprender a andar.

Antes de comenzar a leer y coleccionar libros sobre metodología, gestión de proyectos, pruebas o diseño de software, por favor, empieza leyendo este. Es posible que muchas de las cosas que explica te parezcan obvias a estas alturas, pero creo que es preferible hacerte perder algo de tiempo, a que, por vanidad o desconocimiento, estés descuidando las bases. En todo caso, creo que es imposible no aprender al menos una cosa nueva en cada capítulo, independientemente de tu nivel.

El libro está dividido en tres partes, siendo los 13 primeros capítulos consejos razonados de cómo escribir código limpio, divididos por temáticas. Una lectura muy amena en la que se habla del aspecto que deberían tener, para que nuestro código sea limpio, los nombres, funciones, comentarios, clases, objetos, estructuras de datos, el manejo de errores y las pruebas unitarias.

El capítulo dedicado a las funciones, por ejemplo, explica que la primera regla al escribir funciones es que tienen que ser cortas; la segunda, que tienen que ser aún más cortas. También habla de la necesidad de que cada función haga una única cosa (SRP), de limitar el nivel de anidamiento y el número de parámetros, o de por qué los parámetros booleanos a modo de flag son una mala señal.

La segunda parte es el trabajo duro, donde realmente interiorizamos los conceptos que hemos estado leyendo. Consiste en un par de capítulos con casos de estudio reales (JUnit y SerialDate) en los que tienes la posibilidad de ver cómo y por qué se aplican distintas refactorizaciones para obtener, paso a paso, un código mucho más legible. Ambos ejemplos están escritos en Java, aunque no es necesario conocer el lenguaje para seguirlos. Sólo estar familiarizados con lenguajes similares.

La tercera y última parte consiste en un resumen de los olores y heurísticas explicados a través del libro, que puede servir a modo de repaso y referencia, y para empapelar la pared de alguna que otra oficina que yo conozco.

Si terminas por leer Clean Code, cosa que recomiendo encarecidamente, y te quedas con ganas de más, también me gustaría recomendarte Code Complete, uno de mis libros preferidos sobre programación. Cambiarán totalmente tu forma de entender la programación.

El código ravioli es un patrón que encontramos asociado al paradigma orientado a objetos y que consiste en la creación de un cierto número de pequeñas clases débilmente acopladas, cada una de las cuales contiene algo de “carne” para el sistema, siendo estas fácilmente modificables o reemplazables sin afectar al resto de la aplicación. El código ravioli puede convertirse en un anti patrón si el número de clases crece hasta tal punto que ya nadie sabe muy bien dónde ocurre cada cosa.

El código lasaña es un patrón arquitectónico. Describe una situación ideal en la que el software adopta una estructura dividida en capas, simple, y fácil de entender, con una clara separación de responsabilidades.

El código espagueti con albóndigas, por último, se refiere a código espagueti supuestamente orientado a objetos (de ahí las albóndigas).

Si alguna vez practicaste kárate o judo estarás familiarizado con el concepto de kata (型 ó 形), término japonés que significa literalmente “forma”, y que designa conjuntos de movimientos prefijados que se utilizan para aprender y practicar diversas técnicas, así como para mejorar la precisión, la fluidez o la velocidad con las que estas se ejecutan. El kata Heian Shodan del estilo Shotokan, por ejemplo, uno de los primeros que aprende un estudiante, permite practicar algunas de las técnicas más elementales del kárate, como giros, desplazamientos y golpes de puño.

El concepto de kata, no obstante, no es exclusivo de las artes marciales. Lo podemos encontrar también en otros ámbitos de la tradición japonesa, como son el teatro kabuki, la caligrafía, o la ceremonia del té.

Aplicado a la programación, el concepto de kata de código, acuñado por Dave Thomas, co-autor de “The Pragmatic Programmer”, del que os hablé en 10 libros míticos sobre programación que todo desarrollador debería leer, se traduce en pequeños ejercicios, de menos de 1 hora de duración, que nos ayudan a aprender y mejorar; especialmente, pequeños retos de programación diseñados por terceros, con un propósito específico en mente.

Las katas de código, de igual forma que las katas de las artes marciales, se pueden practicar sólos o por parejas, siguiendo las mejores tradiciones de las metodologías ágiles (pair programming), y pudiendo así beneficiarse de los intercambios de opiniones, y las sugerencias de la otra persona. Igualmente, así como en el kárate se utilizan los combates de práctica (kumité) como sistema fundamental de aprendizaje, también es interesante publicar nuestras soluciones y compararlas con las de otros programadores, embarcándonos en una sana competición por la búsqueda de la mejor solución posible.

Si estás interesado en el concepto de kata de código, no dudes en apuntarte en tu dojo de programación más cercano… ¡o crear uno tú mismo!

Un ejemplo de este tipo de herramientas es la aplicación GPL ProGuard que permite, además de ofuscar nuestras clases Java, optimizarlas, comprimirlas y añadirles información de preverificación, de forma que la carga de las clases en Java SE 6 y Java ME 6 sea más rápida y más eficiente.

La herramienta funciona buscando primeramente clases, campos, métodos y atributos no utilizados, los cuáles elimina; pasa entonces a optimizar el bytecode y eliminar instrucciones innecesarias; y, por último, elimina la información de depuración y renombra las clases, campos y métodos restantes utilizando nombres cortos y poco legibles.

PMD se puede utilizar desde linea de comandos, o puede integrarse con multitud de IDEs y herramientas, como Eclipse, NetBeans, Maven o JEdit. Y aunque algunos de los casos que comprueba PMD ya se tengan en cuenta en Eclipse, sigue siendo una utilidad muy interesante para añadir a nuestra caja de herramientas.

Para instalar el plugin de PMD para Eclipse tenemos que añadir la URL desde la que actualizar el software, http://pmd.sourceforge.net/eclipse, en el diálogo Help -> Software updates -> Available Software -> Add Site, marcar el componente correspondiente dependiendo de nuestra versión de Eclipse y seleccionar Install.

Una vez terminado el proceso podremos gestionar las reglas de PMD desde Window -> Preferences -> PMD -> Rules Configuration. En la misma sección también podemos añadir nuevas reglas utilizando consultas XPath.

Al instalar PMD tendremos acceso a una nueva perspectiva a la que podemos acceder desde Window -> Open Perspective -> Other -> PMD. Para empezar a utilizar PMD haremos clic con el botón derecho sobre el proyecto, el paquete o la clase que queramos comprobar y seleccionaremos PMD -> Check code with PMD.

En la vista Violations Overview podremos ver un resumen de las reglas que incumple nuestro código, con el nombre de la regla, el número de violaciones por paquete, clase y método y el número de violaciones cada 1000 líneas de código.

En Violations Outline podremos ver una pequeña descripción de la regla que rompe nuestro código, asi como la línea de código en el que se encontró el error. Si hacemos clic sobre una de las entradas de la lista se abrirá la clase correspondiente en la línea a corregir. Si necesitamos más información sobre el error podemos hacer clic sobre este y seleccionar Show Details, donde podremos consultar una descripción completa de la regla, asi como ejemplos y la expresión XPath utilizada.

La forma más sencilla de instalar este plugin es utilizar el sistema de actualizaciones de software de Eclipse. En el diálogo Help -> Software updates -> Available Software -> Add Site introducimos la URL desde la que instalar el plugin, “http://eclipse-cs.sourceforge.net/update”, marcamos nuestra nueva fuente y seleccionamos Install.

Si entramos ahora en Window -> Preferences ->Checkstyle veremos las opciones de configuración relativas a Checkstyle. Como vemos en Global Check Configurations, Checkstyle utiliza por defecto las convenciones de la guía de estilo de Sun (Sun Checks), pero podemos editarlas o crear un nuevo conjunto de reglas fácilmente. El plugin también incluye un conjunto de normas basadas en las convenciones de Sun, ligeramente modificadas para adaptarse mejor a la configuración por defecto del formateador de código de Eclipse: Sun Checks (Eclipse).

Para activar Checkstyle para uno de nuestros proyectos haremos clic con el botón derecho sobre él, seleccionaremos Properties y en la sección dedicada a Checkstyle marcaremos Checkstyle active for this project. En esta sección podemos seleccionar también el conjunto de normas que nuestro proyecto debe de seguir, asi como posibles excepciones.

Una vez activado Checkstyle para el proyecto veremos los Warnings relativos a los estándares de código en la vista Problems, así como en el propio editor, donde las advertencias se muestran con fondo amarillo. También podemos recurrir a la vista Checkstyle violations (Window -> Show view -> Checkstyle -> Checkstyle violations), que está más especializada y permite agrupar los problemas, generar informes en formato rtf, y lanzar la vista Checkstyle violations chart, con un gráfico de tarta con los distintos problemas encontrados en el código.

Escribir código sin pruebas automátizadas es como intentar usar ladrillos sin cemento.

– Anónimo

1. Java (173 votos)
2. PHP (107 votos)
3. C (86 votos)
4. C++ (47 votos)
5. Python (37 votos)

Otros meritorios participantes han sido Visual Basic (35), C# (30), Ruby (10), COBOL (7), PL/SQL (7), Perl (6) o JavaScript (6).

Gracias a todos los que respondisteis a la encuesta