Introduciendo variables locales adicionales como reemplazo de comentarios

12

¿Es un buen estilo usar variables locales adicionales técnicamente superfluas para describir lo que está sucediendo?

Por ejemplo:

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

Cuando se trata de gastos generales técnicos, espero que el compilador optimice esta línea adicional de distancia. ¿Pero es considerado un código innecesario inflado? En mi opinión, reduce el riesgo de comentarios obsoletos.

    
pregunta BooleanAssange 14.11.2016 - 12:18

1 respuesta

16

¿Cuál es el costo de tener una variable adicional? En la mayoría de los idiomas, ninguno, tanto en lenguajes compilados como interpretados.

¿Cuál es el beneficio de esto?

  • De manera similar a extraer la expresión booleana críptica a un método separado, está disminuyendo el riesgo de código duplicado , pero ligeramente menor que en el caso de un método diferente. Si la expresión condicional se reutiliza dentro del propio método, podrá reutilizar la variable; si la expresión aparece en un método diferente, no lo harás.

    Tenga en cuenta que, a menos que su lenguaje de programación le permita tener variables locales inmutables o que tenga una forma de imponer, en términos de estilo, que ninguna de las variables se reasigne, dicha refactorización podría ser riesgosa a largo plazo. Si se cambia el valor de la variable, podría ser muy difícil razonar sobre el código.

  • Estás reduciendo el riesgo de que la documentación se desincronice con el código . Los desarrolladores tienden a actualizar los nombres de variables y métodos más fácilmente que los comentarios. Por lo tanto, no es raro ver códigos como:

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

La expresión probablemente comenzó con if (message.author == currentUser) y luego evolucionó para manejar el caso de los mensajes bloqueados y los administradores que no necesitan ser autores y no se preocupan por las cosas bloqueadas; sin embargo, el comentario no ha reflejado ninguno de esos cambios.

Ambos beneficios no son particularmente importantes, pero dado el bajo costo de las variables adicionales, puede considerar su uso.

Tenga en cuenta que si su expresión booleana se vuelve demasiado compleja: ²

  • Extraerlo a un método separado , y:
  • Refactorízalo en múltiples expresiones booleanas simples.

El ejemplo anterior se convierte en:

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

¹ Fuente: mi propia observación de mis compañeros que desarrollan software principalmente para negocios; YMMV. Una investigación real puede mostrar diferentes resultados. Personalmente, supongo que cuando los desarrolladores leen el código, se centran en el código , y los comentarios son documentación, no código; por lo tanto, generalmente no leen los comentarios, por lo que sería difícil esperar que los actualicen.

² El umbral demasiado complejo se define con una fórmula simple: si la mitad de los desarrolladores que revisan tu código expresan la intención de asesinarte, se alcanza el umbral. La expresión booleana de arriba es lo suficientemente simple como para requerir una refactorización; sin embargo, cuatro partes en una fila if ((a && b) || (c && d)) lo harían potencialmente refactorable. Tenga en cuenta que si la expresión es plana, la cantidad de partes en su mayoría es irrelevante: if (a || b || c || d || ... || z) es lo suficientemente legible.

    
respondido por el Arseni Mourzenko 14.11.2016 - 13:11

Lea otras preguntas en las etiquetas