Hediondez del código , la enciclopedia libre

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.

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.

• 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.

• Crisis del software
• Antipatrón de diseño
• Entropía del software
• Pudrición del software
• Principio de sustitución de Liskov

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