Hediondez del código

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

En programación de computadores, la hediondez del código (code smell en inglés) 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 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 cuando 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.

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.[1] La hediondez del código es también un término usado por programadores que utilizan técnicas ágiles.[2]

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

Hediondeces de código comunes[editar]

  • 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. Ver objeto Dios.
  • 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.

Referencias[editar]

  1. Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2. 
  2. Andrew Binstock (27-06-2011). «In Praise Of Small Code». Information Week. Consultado el 27-06-2011.

Véase también[editar]

Enlaces externos[editar]