¿Deberíamos estar buscando códigos mentirosos?

9

Esto se refiere a una discusión en una respuesta y los comentarios de esta pregunta: ¿Qué pasa con la aversión a la documentación en la industria? . La respuesta afirmaba que "el código no puede mentir" y, por lo tanto, debería ser la ubicación de acceso en lugar de la documentación. Varios comentarios señalaron que "el código puede mentir". Hay verdad en ambos lados, al menos en parte debido a lo mal que se maneja la documentación de manera inapropiada.

¿Deberíamos estar atentos al código mentiroso y compararlo con cualquier documentación existente? ¿O suele ser la mejor fuente de lo que necesita hacer? Si es un código ágil, ¿es menos probable que mienta o ese código no puede mentir en absoluto?

documentation

— jueves
fuente

1

¿Podría aclarar qué quiere decir con "mentira"? No deberíamos tener que referirnos a los comentarios en otra pregunta para obtener su contexto.

— user16764

@ user16764 Sin mirar el otro hilo, lo primero que se me viene a la mente es el concurso Underhanded C

— Izkata

Si la documentación dice que el código debe hacer foo, y el código hace una barra, ¿eso significa que la barra es lo que debería hacer el código? ¿O estamos asumiendo que la barra es la acción correcta porque nunca leemos la documentación, porque el código siempre es correcto?

— thursdaysgeek

Si el código ha sido aceptado como barra, la documentación es incorrecta y está desactualizada. Pero si foo y bar están estrechamente relacionados, y los usuarios no se han dado cuenta de que no resuelve sus problemas como esperaban, ¿entonces quizás la documentación sobre foo no está equivocada? En otras palabras, ¿es el código realmente el todo y el final de todo lo que el código debería estar haciendo?

— thursdaysgeek

9

En palabras simples:

Sí , debes buscar un código mentiroso y hacerlo decir la verdad. Pero no comparándolo con la documentación. Ese sería un método para detectar la documentación que miente.

Hay varias formas en que el código puede mentir, de las cuales mencionaré solo algunas:

Bloques de código que nunca se ejecutan porque las condiciones nunca se cumplen. El código te está mintiendo sobre cuánto hace.
El código que agrega complejidad innecesaria miente sobre cuán complejo es realmente el problema.
El código sin convenciones de nomenclatura miente porque lo engaña haciéndole creer que hace algo diferente a lo que realmente está haciendo.

Cuanto más corto es, menos miente. Es evidente por sí mismo.

Cuanto menos complicado es el código, más transparente es. Entonces yace menos.

Los trucos de sintaxis arcana yacen mucho. Prefiere algoritmos claros, paso a paso. Mienten menos.

Una buena herramienta de análisis de código estático puede ayudarlo a encontrar el código que miente.

Además, una buena batería de prueba automatizada obliga al código a decir la verdad.

— Tulains Córdova
fuente

44

The shorter and terser the code is, the less it lies. It's self evident. Apenas diría eso. En mi experiencia, cuanto más corto y terser es el código, más oportunidades tiene para barrer mentiras debajo de la alfombra, generalmente ocultándolos en llamadas de funciones engañosas.

— Mason Wheeler

@MasonWheeler Tienes razón. Edité la parte "concisa".

— Tulains Córdova

No estoy convencido por "Código sin convenciones de nombres mentiras". Ciertamente es malo, pero ¿cómo puede estar mintiendo si no te está diciendo nada? "¡No te lo digo!" es tercamente obstructivo y poco informativo pero no engañoso. Seguramente la "mentira" es cuando existe una convención de nomenclatura, pero se usa de una manera que no coincide con lo que realmente hace el código, por ejemplo, si está usando húngaro (¡qué asco!) Pero ocasionalmente tiene el prefijo ppara una variable que No es un puntero.

— Steve314

2

En realidad, lo que estás sugiriendo podría describirse mejor como "sofistería" que simplemente como "mentiras". El sofisterio tiende a ser detallado y complicado precisamente para que sea difícil ver las fallas lógicas, y es superficialmente inteligente y seguro para que las personas tengan miedo de cuestionarlo en caso de que se vean estúpidos.

— Steve314

Otro ejemplo: Código que cambia el lenguaje subyacente o las propiedades de tiempo de ejecución, por ejemplo, redefiniendo o enmascarando el comportamiento primitivo.

— JustinC

6

El código no puede mentir.

Lo que está en el código es lo que su programa está haciendo actualmente, sin importar la documentación, el control de calidad o el cliente. Especialmente si su código ha sido publicado y ha estado en el campo por un tiempo, ese comportamiento esperado no debe ser ignorado.

El código ciertamente puede ser incorrecto . Ciertamente puede ser engañoso en su denominación u organización. Ciertamente puede ser ilegible.

Pero si desea la fuente de la verdad sobre lo que está haciendo su código , no lo que se supone que debe hacer, no lo que fue diseñado para hacer, no lo que pensó que estaba haciendo ... si necesita saber lo que realmente está haciendo, Ve al código.

— Telastyn
fuente

Hay una escuela de pensamiento de que si eres deliberadamente engañoso pero pedantemente correcto, entonces no estás mintiendo. No es la única escuela de pensamiento. Por ejemplo, tengo una edición anterior de Detección de mentiras y engaños de Aldert Vrij . Una de las primeras cosas que esto hace es considerar varias definiciones de mentira y engaño, eligiendo incluir declaraciones pedagógicamente correctas pero deliberadamente engañosas, en parte porque esa es una comprensión común de todos modos.

— Steve314

Lo siento, pero decir "pero era pedante correcto" no significa que no se te pueda llamar mentiroso, incluso si la gente no responde, todavía lo saben.

— Steve314

@ steve314 - pssh. La pregunta original fue sobre los comentarios. Es absurdo construir un hombre de paja para estos escenarios raros donde el código se nombra de manera engañosa para argumentar a favor de comentar (e ignorar el escenario muy común de comentarios desactualizados).

— Telastyn

1

Estoy de acuerdo con eso: no estoy discutiendo el punto que haces, solo la aparente definición de "mentira" que usas mientras lo haces. El código puede mentir, no al compilador, sino ciertamente a los lectores humanos. Incluso es un objetivo intencional en algunos casos: cosas como el concurso de C ofuscado sería un ejemplo relativamente benigno. Sofistería, como sugiero en mi comentario al usuario61852. El hecho de que un compilador vea la mentira no significa que no sea una mentira.

— Steve314

@Telastyn Supongo que nunca ha tenido un filtro que haga una redirección, lo que hace que se produzca un paso a paso en el espacio en blanco y luego ingrese al código que no se invocó desde ese método, para que nunca regrese, ¿verdad? Dios, odio el! @ # $ Java desarrolladores hacen con Java.

— Erik Reppen

0

Usted hace varias preguntas

¿Deberíamos estar atentos al código mentiroso?

¡Por supuesto!

¿Deberíamos comparar [código] con cualquier documentación existente?

Eso nunca podría doler, aunque como se menciona en otras respuestas, la mayoría de las veces esto lo llevará a encontrar problemas en la documentación , no en el código .

¿O es [código] generalmente la mejor fuente para lo que necesita hacer?

Siempre es la mejor fuente de lo que está haciendo. Sin embargo, la mejor fuente de lo que debería hacer el código puede ser (una combinación de) cosas diferentes, siendo las principales:

El código en sí mismo;
El código de llamada;
Comentarios en ese código;
Documentación;
Pruebas unitarias;
Pruebas de integración y regresión;
El programador;
El usuario final;

Cuál es la "mejor" fuente (o combinación de ellas) depende de su situación.

Si es un código ágil, ¿es menos probable que mienta o ese código no puede mentir en absoluto?

No estoy seguro de lo que quiere decir con "código ágil", AFAIK "ágil" generalmente se refiere al proceso de codificación. Suponiendo que quiere decir "código creado en un proceso de programación ágil", creo que es seguro decir que todavía puede mentir. La probabilidad de mentir, en comparación con el código creado en, por ejemplo, proyectos de estilo cascada es un asunto subjetivo (personalmente no creo que haya una gran conexión).

Nota al pie de página
Todo lo anterior está bajo el supuesto de que el código puede mentir, y que este es un ejemplo básico (aunque un poco artificial):

public int DivideByTwo(int input) 
{
    return input / 3;
}

Este es solo un ejemplo en el que diría "mentiras de código", @ user61852 tiene algunos otros (código inalcanzable, complejidad del código que no coincide con la complejidad del problema, mala denominación), y creo que hay muchos más. Wikipedia tiene un resumen bastante decente de mentiras , muchas de ellas se pueden encontrar en código.

Tenga en cuenta que si tiene una discusión con alguien, asegúrese de que la otra persona no quiere decir "código no puede mentir" que "el código hace lo que hace". En esencia, la otra persona aquí está definiendo el uso de una definición de "mentira" que es tan limitada que puede declarar la declaración "el código no puede mentir" como un axioma / verdad básica. En este caso, probablemente sea mejor estar de acuerdo con su axioma.

— Jeroen
fuente

0

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

Puede discutir si la palabra "mentir" es técnicamente apropiada, pero este código implica claramente que x a veces será mayor que 5 y otras no. Si observa el programa completo y descubre que esta función siempre se llama en un solo lugar y que x siempre se establece en un 6 constante, entonces eso es mentira.

Además, el compilador puede haber notado esto, y reemplazado este bloque de código con simplemente

doSomething()

Si no se llama a doADifferentThing en ningún otro lugar de su programa, se puede eliminar por completo del programa.

Si su idioma admite assertalgún tipo, que está desactivado en las compilaciones de producción, cada assertdeclaración es potencialmente una mentira. Un encasillado es otra afirmación que podría ser una mentira.

— MatrixFrog
fuente