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 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 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]
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.
Andrew Binstock (27 de junio de 2011). «In Praise Of Small Code». Information Week. Consultado el 27 de junio de 2011.
Enlaces externos
CodeSmell at c2.com
Overview of many code smells
Datos:Q2295111
Agosto 04, 2021
hediondez, código, programación, computadores, hediondez, código, code, smell, inglés, también, conocido, código, huele, apesta, cualquier, síntoma, código, fuente, programa, posiblemente, indica, problema, más, profundo, hediondeces, código, usualmente, progr. En programacion de computadores la hediondez del codigo code smell en ingles o tambien conocido por codigo que huele o apesta es cualquier sintoma en el codigo fuente de un programa que posiblemente indica un problema mas profundo Las hediondeces del codigo usualmente no son bug de programacion errores no son tecnicamente incorrectos y en realidad no impiden que el programa funcione correctamente En cambio indican deficiencias en el diseno software que puede ralentizar el desarrollo o aumentan el riesgo de errores o fallos en el futuro Indice 1 Contexto 2 Hediondeces de codigo comunes 3 Vease tambien 4 Referencias 5 Enlaces externosContexto EditarA menudo el mas profundo problema insinuado por una hediondez de codigo puede ser descubierto cuando el codigo es sometido a un corto ciclo de retroalimentacion donde es refactorizado en pasos pequenos y controlados y el diseno resultante es examinado para ver si hay mas hediondeces de codigo que indican la necesidad de mas refactorizacion Desde el punto de vista de un programador encargado de realizar la refactorizacion las hediondeces del codigo son heuristicas para indicar cuando hay que refactorizar y que tecnicas de refactorizacion especificas usar Asi una hediondez de codigo es un conductor hacia la refactorizacion El termino parece haber sido acunado por Kent Beck en WardsWiki a finales de 1990 El uso del termino aumento despues de que aparecio en Refactoring Improving the Design of Existing Code Refactorizando Mejorando el diseno del codigo existente 1 La hediondez del codigo es tambien un termino usado por programadores que utilizan tecnicas agiles 2 Determinar lo que es y no es una hediondez de codigo suele ser con frecuencia un juicio subjetivo y puede depender del lenguaje de programacion el desarrollador y la metodologia de desarrollo Existen herramientas como Checkstyle PMD SonarQube y FindBugs para comprobar automaticamente ciertos tipos de hediondeces de codigo Hediondeces de codigo comunes EditarCodigo duplicado existe codigo identico o muy similar en mas de una ubicacion Metodo grande un metodo funcion o procedimiento que ha crecido hasta hacerse demasiado grande Clase grande una clase que ha crecido hasta hacerse demasiado grande Ver objeto Dios Demasiados parametros una larga lista de parametros de un procedimiento o funcion empeora la legibilidad y la calidad del codigo Envidia de caracteristicas una clase que usa excesivamente metodos de otra clase Intimidad inadecuada una clase que tiene dependencias en detalles de implementacion de otra clase Herencia rechazada una clase que sobreescribe un metodo de una clase base de tal manera que el contrato de la clase base no es honrado por la clase derivada Ver principio de sustitucion de Liskov Clase perezosa gorron una clase que hace muy poco Complejidad artificiosa Uso forzado de patrones de diseno demasiado complicados donde uno mas simple seria suficiente Identificadores excesivamente largos en particular el uso de convenciones de nombres para proporcionar desambiguacion que deberia estar implicita en la arquitectura de software identificadores excesivamente cortos el nombre de una variable debe reflejar su funcion 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 programacion Adicionalmente los literales pueden y deben ser externalizados en archivos scripts de recursos cuando sea posible para facilitar la localizacion del software si se pretende implementar en diferentes regiones Supercallback callback excesivos Vease tambien EditarCrisis del software Antipatron de diseno Entropia del software Pudricion del software Principio de sustitucion de LiskovReferencias Editar 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 Enlaces externos EditarCodeSmell at c2 com Taxonomy of code smells Overview of many code smells Datos Q2295111Obtenido de https es wikipedia org w index php title Hediondez del codigo amp oldid 121943871, wikipedia, wiki, leyendo, leer, libro, biblioteca,
