Hediondez del código

En programación de computadores, la hediondez del código (code smell en inglés, o también conocido por código que huele o apesta) es cualquier síntoma en el código fuente de un programa que posiblemente indica un problema más profundo. Las hediondeces del código usualmente no son bug de programación (errores) -- no son técnicamente incorrectos y en realidad no impiden que el programa funcione correctamente. En cambio, indican deficiencias en el diseño de software que puede ralentizar el desarrollo o aumentan el riesgo de errores o fallos en el futuro.

Contexto

A menudo el más profundo problema insinuado por una hediondez de código puede ser descubierto cuando el código es sometido a un corto ciclo de retroalimentación donde es refactorizado en pasos pequeños y controlados, y el diseño resultante es examinado para ver si hay más hediondeces de código que indican la necesidad de más refactorización. Desde el punto de vista de un programador encargado de realizar la refactorización, las hediondeces del código son heurísticas para indicar cuándo hay que refactorizar, y qué técnicas de refactorización específicas usar. Así, una hediondez de código es un conductor hacia la refactorización.

Factores como la comprensibilidad del código, la facilidad con la que se modifica, la facilidad con la que se puede mejorar para admitir cambios funcionales, la capacidad del código para reutilizarse en entornos diferentes, la capacidad de prueba del código y la confiabilidad del código son factores que se puede utilizar para identificar hediondez del código.^[1]

El término parece haber sido acuñado por Kent Beck en WardsWiki a finales de 1990. El uso del término aumentó después de que apareció en Refactoring: Improving the Design of Existing Code (Refactorizando: Mejorando el diseño del código existente.^[2] La hediondez del código es también un término usado por programadores que utilizan técnicas ágiles.^[3]

Determinar lo que es y no es una hediondez de código suele ser con frecuencia un juicio subjetivo y puede depender del lenguaje de programación, el desarrollador y la metodología de desarrollo. Existen herramientas, como Checkstyle, PMD, SonarQube y FindBugs, para comprobar automáticamente ciertos tipos de hediondeces de código.

Hediondeces de código comunes

Código duplicado: existe código idéntico o muy similar en más de una ubicación.
Método grande: un método, función o procedimiento que ha crecido hasta hacerse demasiado grande.
Clase grande: una clase que ha crecido hasta hacerse demasiado grande. El objeto Dios (del inglés: God Object) es, por ejemplo, una hediondez de código a nivel de clase común. Esta se caracteriza por adjuntar todo tipo de funciones que no suelen ir juntas, por lo que afectan el principio de "separación de intereses"^[4].
Demasiados parámetros: una larga lista de parámetros de un procedimiento o función empeora la legibilidad y la calidad del código.
Envidia de características: una clase que usa excesivamente métodos de otra clase.
Intimidad inadecuada: una clase que tiene dependencias en detalles de implementación de otra clase.
Herencia rechazada: una clase que sobreescribe un método de una clase base de tal manera que el contrato de la clase base no es honrado por la clase derivada. Ver principio de sustitución de Liskov.
Clase perezosa / gorrón: una clase que hace muy poco.
Complejidad artificiosa: Uso forzado de patrones de diseño demasiado complicados, donde uno más simple sería suficiente.
Identificadores excesivamente largos: en particular, el uso de convenciones de nombres para proporcionar desambiguación que debería estar implícita en la arquitectura de software.
identificadores excesivamente cortos: el nombre de una variable debe reflejar su función, a menos que sea obvio.
Excesivo uso de literales: estos deben codificarse como constantes con nombre, para mejorar la legibilidad y para evitar errores de programación. Adicionalmente, los literales pueden y deben ser externalizados en archivos/scripts de recursos cuando sea posible, para facilitar la localización del software si se pretende implementar en diferentes regiones.
Supercallback: callback excesivos.

Véase también

Referencias

↑ Suryanarayana, Girish, Ganesh Samarthyam, and Tushar Sharma. Refactoring for Software Design Smells : Managing Technical Debt / Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. 1st edition. Waltham, Massachusetts ; Morgan Kaufmann, 2015. Print.
↑ Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.
↑ Andrew Binstock (27 de junio de 2011). «In Praise Of Small Code». Information Week. Consultado el 27 de junio de 2011.
↑ «Code smell». IONOS Digital Guide. Consultado el 25 de noviembre de 2022.

Enlaces externos

CodeSmell at c2.com
Taxonomy of code smells
Overview of many code smells Archivado el 18 de enero de 2013 en Wayback Machine.

Datos: Q2295111

[1] Suryanarayana, Girish, Ganesh Samarthyam, and Tushar Sharma. Refactoring for Software Design Smells : Managing Technical Debt / Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. 1st edition. Waltham, Massachusetts ; Morgan Kaufmann, 2015. Print.

[2] Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.

[In_Praise_Of_Small_Code-3] Andrew Binstock (27 de junio de 2011). «In Praise Of Small Code». Information Week. Consultado el 27 de junio de 2011.

[4] «Code smell». IONOS Digital Guide. Consultado el 25 de noviembre de 2022.

[1]

[2]

[3]

[4]