En el post anterior, hemos examinado los primeros resultados del análisis de código fuente de Word 1.1a (1990).
Contamos con 349 archivos, que no es enorme, pero con un tamaño alto: en promedio, más de 470 LOC (Lines Of Code), y muchos de ellos más allá de 1 000 LOC. Las métricas de complejidad también son altas, y el nivel de comentarios bastante bajo, pero probablemente era normal hace más de 40 años.
El muy bajo nivel de duplicación hace pensar que todos los componentes necesarios para implementar una funcionalidad se encuentran en un mismo archivo, por lo que explica el tamaño y la complejidad de muchos de ellos. Parece que la consigna era: prioridad a la eficiencia, luego la legibilidad y la comprensión del código en segundo plano.
¿Y ahora, que podemos ver del cumplimiento de las buenas prácticas de programación? Lo examinamos en este segundo post.
Cumplimiento de las buenas prácticas
El ‘Treemap of Components’ muestra un bajo nivel de cumplimiento de las buena prácticas de programación.
Los archivos más numerosos y más complejos están en el directorio principal (‘Opus’), y tienen entre el 20% y el 50% ‘Rules compliance’ en la mayoría de los casos.
En total, más de 40.000 ‘Issues’, la mayoría de tipo ‘Major’ y una deuda técnica de más de 1 200 días.
Ahora debemos examinar las normas infringidas por nivel de criticidad. Hay que recordarnos que he utilizado el Quality Profile predeterminado, ‘out of the box’ como se dice en Inglés.
Blockers
No encontramos violaciones de reglas del tipo ‘Blocker’. Muy bien, es lo que deseamos ver en cualquier aplicación. Pero ¿qué son estas reglas tan respetadas?
La primera es una buena práctica para el manejo de excepciones en C++. Así que no es una sorpresa si se respeta completamente aquí: no hay un solo ‘throw’ en toda la aplicación.
La segunda se refiere al uso de Trigraphs, lo que no estoy seguro de que existían en acuel tiempo. No soy un experto en lenguaje C, pero me parece que los ‘trigrafos’ fueron introducidos por la norma C89, mucho después de 1980. De todos modos, sabemos que no tenemos estos defectos.
Criticals
Hemos encontrado 753 defectos de tipo crítico, la mayoría de ellos en dos reglas.
La primera se refiere al uso de ‘goto’ para hacer un ‘jump’, es decir un salto para ir directamente a una zona distinta del código. El ‘goto’ se convirtió en el símbolo del código ‘espagueti’, cuya lógica algorítmica es difícil de entender, debido al número excesivo de referencias en todas las direcciones. No siempre es posible evitar los ‘goto’, pero es mejor disponer de ellos en el mismo bloque de código, para facilitar la lectura, y por una mejor robustez también.
Son los saltos a las porciones de código imbricadas que son especialmente peligrosos. Un ‘goto’ para un bloque de nivel superior es más fácil de leer, excepto cuando el programa tiene más de 1 000 líneas y el salto te enviará un par de páginas más abajo. Difícil de entender lo que hace el código cuando pasas tu tiempo haciendo viajes entre varias páginas. Resulta extremadamente difícil hacer un cambio sin introducir un error. Los costes de mantenimiento y de QA aumentan proporcionalmente.
La segunda regla indica un uso de operadores lógicos que presenta un riesgo de efectos secundarios debido a que conduce a cambiar un valor que no sea el código de retorno, como una variable global, con consecuencias impredecibles en la ejecución del programa.
Tengamos en cuenta que las 335 ocurrencias encontradas en el código no son necesariamente todas un defecto.
Por ejemplo, en este caso, si estamos seguros de que el ‘DocOpenStDof’ no cambia ningún valor, sino que realiza una acción, como abrir un documento de Word, podemos signalar que no es un defecto, para que no se reconozca ya en los análisis futuros.
La tercera regla es el uso de las constantes en octal, no muy fáciles de leer, y que supone un riesgo de confusión con valores enteros. No se encuentran muchos, y si tenemos en cuenta que ciertas porciones de código de MS-DOS se reutilizaron para escribir esta versión de Word, su presencia no es muy sorprendente.
Major
Las violaciónes ‘Major’ son las más numerosas, con diferencia. No voy a detallar a todas, pero unos breves comentarios sobre las más notables.
La regla más transgredida (más de 9.000 violaciónes) es el uso de ‘braces’ en los tratamientos If-Else. De hecho, el examen del código demuestra que no se utilizan cuando el If o el Else tiene muy pocas líneas, como un simple ‘return’ o ‘goto’. Así que esta ausencia en realidad no es indicativo de una falta de legibilidad del código, pues el espíritu de la norma general está respetado. El problema es que crea excepciones peligrosas, que además he podido encontrar en el código: con cuentas líneas sin estos signos podemos considerar que un tratamiento es menos comprensible?
Probablemente desactivaría del Quality Profile la segunda regla para las reglas de nomenclatura, como suele ser muy a menudo el caso en ‘naming conventions’: que no se respetan no significa que no existen. Y usualmente, prefiero guardarlas en la categoría ‘Minor’.
Las sintaxis de tipo K&R (Kernighan y Richie) son obsoletas hoy en día porque se consideran difíciles de leer, pero no lo eran a principios de los 80s.
La mayoría de las demás violaciónes de tipo ‘Major’ también afectarán a la legibilidad y comprensión del código, como se muestra a continuación.
He configurado este widget para mostrar las reglas ‘Major’ por número de defectos. La gran mayoría son buenas prácticas de programación que recomiendan evitar tratamientos demasiado largos, como ‘Switch cases should not have too many lines’ o ‘Function/methods should not have too many lines’, funciones complejas (‘Avoid too complex function’ para las funciones con más de 20 puntos de Cyclomatic Complexity), reglas de nomenclatura (‘Literal suffixes shall be upper case’), etc.
En realidad son (relativamente) muy pocos los defectos ‘Major’ que pueden afectar a la fiabilidad y robustez de la aplicación.
Minor
Esto también es cierto para las reglas de tipo ‘Minor’ que son, sin embargo, menos numerosas.
El análisis de los ‘Issues’ encontrados en el código de esta primera versión de Word confirma nuestra evaluación inicial. todo parece indicar que las prioridades han sido centradas en la eficiencia y la fiabilidad, ya que las violaciónes de este tipo son menos numerosas. Las infracciones a las buenas prácticas de mantenimiento y la capacidad de evolución del código representan la gran mayoría de los problemas encontrados, lo que explica una deuda técnica muy importante para una primera versión de esta aplicación.
Ciertamente hay algunas reglas, como las de ‘naming conventions’ por ejemplo, que se pueden desactivar. Yo no quería cambiar el Quality Profile predeterminado para el análisis del código, pero seguramente se debería adaptarlo a las características de una aplicación ‘Legacy’ en C.
Sin embargo, el próximo post nos permitirá ver algunos casos en los que es mejor comenzar nuestro proceso de evaluación de esta manera.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.