Código limpio: Deja de comentar

Código limpio: Deja de comentar

Esta entrada está disponible en video

Puedes encontrar una versión en video de esta entrada en nuestro canal de youtube.

Código Limpio

El libro Clean Code o Código Limpo es considerado por muchos como "la biblia" del desarrollo de software. Probablemente esta es una afirmación exagerada, sin embargo no se puede negar que es un gran libro que merece la pena leer. En esta serie de entradas analizamos los principales capítulos del libro clean code publicado por Robert C Martin en el año 2008.

Se han escrito mil entradas sobre el que se considera uno de los más importantes libros sobre filosofía de desarrollo de software, pero nosotros en esta serie de entradas queremos profundizar un poco más en cada uno de los capítulos. Si te dedicas a programar y te interesa mejorar en tu profesión quedate. A lo largo de esta serie de entradas vamos a aprender un montón de cosas.


Si lo deseas puedes ver el resto de entradas de la serie: Código Limpio

En esta entrada vamos a analizar cuándo y cómo es conveniente el uso de comentarios durante la fase de desarrollo de software.

bloques de código

Por regla general deberías evitar el uso de comentarios. Los comentarios pueden parecer una herramienta muy útil ya que cuando estamos desarrollando puede que nos encontremos con que queremos explicar mejor cómo funciona nuestro código o por que hemos tomado una determinada decisión.

Pero cuando usamos un comentario de código donde antes teníamos un problema: que nuestro código no era suficientemente sencillo de entender, ahora tenemos dos: nuestro código sigue sin entenderse con facilidad, y ahora además debo ocuparme de mantener los comentarios que he realizado.

Puedes pensar que mantener ese comentario no es mucho trabajo, pero que tal si esa energía qué has gastado en mantener un comentario la hubieras gastado en hacer algo más productivo. ¿mejor, no?.

Vemos un ejemplo con el TokenStorage del componente Security de Symfony.

namespace Symfony\Component\Security\Core\Authentication\Token\Storage;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Contracts\Service\ResetInterface;

/**
 * TokenStorage contains a TokenInterface.
 */
class TokenStorage implements TokenStorageInterface, ResetInterface
{
    // ..
    public function setToken(TokenInterface $token = null)
    {
        if ($token) {
            // ensure any initializer is called
            $this->getToken();
        }

        $this->initializer = null;
        $this->token = $token;
    }
    //..
}

El autor de este código necesitaba hacer algunas llamadas antes de configurar el token. Se dio cuenta que que no era sencillo de entender y que otra persona que viniera detrás probablemente no entendería el motivo de esa llamada, asi que utilizó un comentario para aclararlo todo. ¿Pero que te parece si hubiera hecho esto?

namespace Symfony\Component\Security\Core\Authentication\Token\Storage;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Contracts\Service\ResetInterface;

/**
 * TokenStorage contains a TokenInterface.
 */
class TokenStorage implements TokenStorageInterface, ResetInterface
{
    // ..
    public function setToken(TokenInterface $token = null)
    {
        if ($token) {
            $this->callInitializer();
        }

        $this->initializer = null;
        $this->token = $token;
    }

    private function callInitializer(): void
    {
        $this->getToken();
    }
    //..
}

Como ves hemos eliminado el comentario y hemos mantenido e incluso mejorado la expresividad, ya que el código es igual de explícito. Por lo tanto siempre que nos veamos en la necesidad de añadir comentarios, debemos plantearnos si podríamos mejorar la expresividad de nuestro código mejorando los nombres que estamos utilizando o extrayendo métodos como en el ejemplo.

DocBlock y documentación autogenerada

Algunos editores de texto añaden documentación de forma más o menos automática que permite indicar los tipos de los argumentos y del valor devuelto, así como información adicional.

Veamos un ejemplo

    /**
     * get movements
     *
     * @return array
     */
    public function getMovements()
    {
        return $this->movements;
    }

Este tipo de documentación no aporta ningún valor adicional ya que simplemente está repitiendo lo mismo que ya dice el nombre de la función. Quizá esto tenía sentido antes de la versión 7, para ayudar al IDE en el autocompletado. Pero a partir de esta versión es mucho mejor eliminar estos comentarios y utilizar el tipado nativo del lenguaje.

   public function getMovements(): array
    {
        return $this->movements;
    }

Usos permitidos

Por supuesto el autor contempla algunos casos en los que sí estaría permitido y justificado el uso de comentarios.

Licencias y textos legales

Es un uso completamente justificado el incluir la licencia y otros textos legales en el encabezado de nuestros ficheros. Además esto no supone ningún trabajo adicional, por que es habitual utilizar sistemas que se encargan de añadir estos comentarios de forma automática, y además los IDE suelen ocultarlos por lo que no molestan.

APIs

Si estás construyendo una api y probablemente quieras generar la documentación a través de algún sistema automático, sí estaría justificado el incluir toda esta información adicional en tu código.

¿Quieres ser una bestia del desarrollo de software?
¡Continúa con nosotros en YouTube!

Todas las semanas un nuevo vídeo sobre desarrollo de software en tu bandeja de entrada.

Tranquilo, no te vamos a enviar spam.