Gabriel Brooks
0 
4268
901
UNA olor a código es un fragmento de código o patrón de codificación general que parece indicar un problema más profundo en la estructura general y el diseño de una base de código.
Piense en un olor a código como cualquier signo que sugiera que se debe refactorizar una sección de código. No es que el código tenga errores o no funcione, a menudo, el código maloliente funciona bien, pero el código maloliente es a menudo difícil de mantener y extender, lo que puede conducir a problemas técnicos (especialmente en proyectos más grandes).
En este artículo, destacaremos 10 de los olores de código más comunes, qué buscar y cómo desodorizarlos. Si eres un nuevo programador Cómo aprender a programar sin todo el estrés Cómo aprender a programar sin todo el estrés Tal vez hayas decidido seguir con la programación, ya sea para una carrera o simplemente como un pasatiempo. ¡Excelente! Pero tal vez estés empezando a sentirte abrumado. No muy bien. Aquí hay ayuda para facilitar su viaje. , evítelos y su código será notablemente mejor!
1. Acoplamiento apretado
El problema
El acoplamiento apretado es cuando dos objetos son tan dependientes de los datos y / o funciones del otro que modificar uno requiere modificar el otro. Cuando dos objetos están demasiado unidos, hacer cambios en el código puede ser una pesadilla y es más probable que introduzcas errores con cada cambio.
Por ejemplo:
Trabajador de clase Bike bike = new Bike (); viaje público vacío () bike.drive (); En este caso, Worker y Bike están estrechamente acoplados. ¿Qué pasaría si un día quisieras conducir un automóvil en lugar de una bicicleta para tu viaje diario? Tendría que ingresar a la clase Worker y reemplazar todo el código relacionado con Bike con código relacionado con Car. Es desordenado y propenso a errores.
La solución
Puede aflojar el acoplamiento agregando una capa de abstracción. En este caso, la clase Worker no solo quiere conducir Bicicletas, sino también Autos, y quizás Camiones, posiblemente incluso Scooters. Todos estos son vehículos, ¿no? Por lo tanto, cree una interfaz de vehículo, que le permite insertar y reemplazar diferentes tipos de vehículos según lo desee:
trabajador de clase vehículo vehículo; Public void changeVehicle (Vehículo v) vehículo = v; public void commute () vehicle.drive (); interfaz del vehículo void drive (); class Bike implementa el vehículo public void drive () class Car implementa el vehículo public void drive () 2. Objetos de Dios
El problema
Un objeto de Dios es una clase / módulo masivo que contiene demasiadas variables y funciones. Eso “sabe demasiado” y “hace demasiado,” lo cual es problemático por dos razones. Primero, otras clases / módulos se vuelven demasiado dependientes de éste para los datos (acoplamiento estrecho). En segundo lugar, la estructura general del programa se vuelve confusa a medida que todo se apiña en el mismo lugar..
La solución
Tome un objeto de Dios, separe sus datos y funciones de acuerdo con los problemas que existen para resolver, luego convierta esas agrupaciones en objetos. Si tiene un objeto de Dios, puede ser mejor como composición de muchos objetos más pequeños..
Por ejemplo, suponga que tiene una clase de usuario monstruosa:
usuario de clase nombre de usuario de cadena pública; contraseña de cadena pública; Dirección de cadena pública; código postal de cadena pública; public int age;… public String getUsername () return username; public void setUsername (String u) username = u; Puede convertirlo en una composición de lo siguiente:
clase Usuario Credenciales credenciales; Perfil perfil; ... credenciales de clase nombre de usuario de cadena pública; contraseña de cadena pública; ... cadena pública getUsername () return username; public void setUsername (String u) username = u; La próxima vez que necesite modificar los procedimientos de inicio de sesión, no tiene que rastrear una clase de usuario masiva porque la clase de credenciales es más manejable!
3. Funciones largas
El problema
Una función larga es exactamente lo que parece: una función que ha crecido demasiado. Si bien no hay un número específico para cuántas líneas de código hay “demasiado largo” para una función, es una de esas cosas donde la sabes cuando la ves. Es más o menos una versión más estrecha del problema del objeto de Dios: una función larga tiene demasiadas responsabilidades.
La solución
Las funciones largas deben dividirse en muchas subfunciones, donde cada subfunción está diseñada para manejar una sola tarea o problema. Idealmente, la función larga original se convertirá en una lista de llamadas de subfunción, haciendo que el código sea más limpio y fácil de leer..
4. Parámetros excesivos
El problema
Una función (o constructor de clase) que requiere demasiados parámetros es problemática por dos razones. Primero, hace que el código sea menos legible y hace que sea más difícil de probar. Pero segundo, y más importante, puede indicar que el propósito de la función es demasiado ambiguo y está tratando de manejar demasiadas responsabilidades..
La solución
Mientras “demasiados” es subjetivo para una lista de parámetros, recomendamos desconfiar de cualquier función que tenga más de 3 parámetros. Claro, a veces tiene sentido tener una sola función con 5 o incluso 6 parámetros, pero solo si hay una buena razón para ello..
La mayoría de las veces, no hay una y el código sería mejor dividir esa función en dos o más funciones diferentes. A diferencia del “Funciones largas” olor a código, este no se puede resolver simplemente reemplazando el código con subfunciones: la función en sí misma debe dividirse y dividirse en funciones separadas que cubran responsabilidades separadas.
5. Identificadores mal nombrados
El problema
Nombres de variables de una o dos letras. Nombres de funciones anodinos. Nombres de clase excesivamente adornados. Marcar nombres de variables con su tipo (por ejemplo, b_isCounted para una variable booleana). Y lo peor de todo, mezclar diferentes esquemas de nombres en una sola base de código. Todo esto da como resultado un código difícil de leer, difícil de entender y difícil de mantener..
La solución
Elegir buenos nombres para variables, funciones y clases es una habilidad difícil de aprender. Si se está uniendo a un proyecto existente, analícelo y vea cómo se nombran los identificadores existentes. Si hay una guía de estilo, memorícela y adhiérase a ella. Para nuevos proyectos, considere formar su propia guía de estilo y cúmplala.
En general, los nombres de las variables deben ser cortos pero descriptivos. Los nombres de las funciones normalmente deben tener al menos un verbo y debe ser inmediatamente obvio lo que hace la función solo por su nombre, pero evite la acumulación de palabras. Lo mismo ocurre con los nombres de las clases..
6. Números mágicos
El problema
Estás navegando a través de algún código que (con suerte) alguien más escribió y ves algunos números codificados. Tal vez son parte de una declaración if, o tal vez parte de algunos cálculos arcanos que no parecen tener sentido. Necesita modificar la función, pero no puede entender lo que significan los números. Rascarse la cabeza.
La solución
Al escribir código, estos llamados “números mágicos” debe evitarse a toda costa. Los números codificados tienen sentido en el momento en que se escriben, pero pueden perder rápidamente todo significado, especialmente cuando alguien más intenta mantener su código.
Una solución es dejar comentarios que expliquen el número, pero la mejor opción es convertir números mágicos en variables constantes (para cálculos) o enumeraciones (para declaraciones condicionales y declaraciones de cambio). Al dar un nombre a los números mágicos, el código se vuelve infinitamente más legible de un vistazo y menos propenso a cambios con errores.
7. Anidamiento profundo
El problema
Hay dos formas principales de terminar con un código profundamente anidado: bucles y sentencias condicionales. El código profundamente anidado no siempre es malo, pero puede ser problemático porque puede ser difícil de analizar (especialmente si las variables no se nombran bien) e incluso más difícil de modificar.
La solución
Si te encuentras escribiendo un bucle for doble, triple o incluso cuádruple, entonces tu código puede estar tratando de llegar demasiado lejos de sí mismo para encontrar datos. En su lugar, proporcione una forma de solicitar los datos a través de una llamada a la función en cualquier objeto o módulo que contenga los datos.
Por otro lado, las declaraciones condicionales profundamente anidadas son a menudo una señal de que estás tratando de manejar demasiada lógica en una sola función o clase. De hecho, la anidación profunda y las funciones largas tienden a ir de la mano. Si su código tiene sentencias de cambio masivas o sentencias anidadas if-then-else, puede implementar una máquina de estado o un patrón de estrategia.
El anidamiento profundo es particularmente frecuente entre los programadores de juegos inexpertos 5 Herramientas de software de desarrollo de juegos gratis para hacer tus propios juegos 5 Herramientas de software de desarrollo de juegos gratis para hacer tus propios juegos El software de desarrollo de juegos gratis es una excelente manera de comenzar a hacer videojuegos. Hemos compilado el mejor software de juegos del mercado.. !
8. Excepciones no manejadas
El problema
Las excepciones son poderosas pero se abusa fácilmente. Los programadores perezosos que usan incorrectamente las declaraciones throw-catch pueden hacer que la depuración sea exponencialmente más difícil, si no imposible. Por ejemplo, ignorar o enterrar excepciones atrapadas.
La solución
En lugar de ignorar o enterrar las excepciones detectadas, al menos imprima el seguimiento de la pila de la excepción para que los depuradores tengan algo con qué trabajar. ¡Permitir que su programa falle silenciosamente es una receta para futuros dolores de cabeza, garantizado! Además, prefiera capturar excepciones específicas sobre excepciones generales. Obtenga más información en nuestro artículo sobre cómo manejar las excepciones de la manera correcta Cómo manejar las excepciones de Java de la manera correcta Cómo manejar las excepciones de Java de la manera correcta En este artículo, aprenderá qué son las excepciones de Java, por qué son importantes, cómo usarlos y errores comunes para evitar. .
9. Código duplicado
El problema
Realiza la misma lógica exacta en múltiples áreas no relacionadas de su programa. Más tarde, se da cuenta de que necesita modificar esa lógica, pero no recuerda todos los lugares donde la implementó. Terminas cambiándolo en solo 5 de 8 lugares, lo que resulta en comportamientos defectuosos e inconsistentes.
La solución
El código duplicado es un candidato principal para convertirse en una función. Por ejemplo, supongamos que está desarrollando una aplicación de chat y escribe esto:
String queryUsername = getSomeUsername (); boolean isUserOnline = false; for (String username: onlineUsers) if (username.equals (queryUsername)) isUserOnline = true; if (isUserOnline) …En otro lugar del código, te das cuenta de que debes realizar lo mismo “es este usuario en línea?” comprobar. En lugar de copiar y pegar el bucle, puede convertirlo en una función:
public boolean isUserOnline (String queryUsername) for (String username: onlineUsers) if (username.equals (queryUsername)) return true; falso retorno; Ahora, en cualquier parte de su código, puede usar la verificación isUserOnline (). Si alguna vez necesita modificar esta lógica, puede modificar el método y se aplicará en todas partes.
10. Falta de comentarios
El problema
El código no tiene absolutamente ningún comentario en ningún lado. Sin bloques de documentación para funciones, sin descripciones generales de uso para clases, sin explicaciones de algoritmos, etc. Se podría argumentar que el código bien escrito no necesita comentarios, pero la verdad es que incluso el código mejor escrito aún requiere más energía mental para entender que inglés.
La solución
El objetivo de una base de código fácil de mantener debe ser un código que esté escrito lo suficientemente bien como para que no necesitar comentarios, pero aún los tiene. Y al escribir comentarios, busca comentarios que expliquen por qué existe un fragmento de código en lugar de explicar qué está haciendo Los comentarios son buenos para el alma y la cordura. No los descuides.
Cómo escribir código que no huela
Por obvio que parezca, la mayoría de los olores de código surgen de un malentendido o negligencia de los buenos principios y patrones de programación 10 Principios básicos de programación que todo programador debe seguir trabajando en su software. Con ese fin, aquí hay varios principios de programación para ayudarlo a limpiar su acto. . Por ejemplo, una adhesión sólida al principio DRY elimina la mayoría de las duplicaciones de código, mientras que el dominio del principio de Responsabilidad Única hace que sea casi imposible crear monstruosos objetos de Dios..
También recomendamos leer nuestro artículo sobre cómo escribir un código más limpio 10 consejos para escribir un código más limpio y mejor 10 consejos para escribir un código más limpio y mejor Escribir un código limpio parece más fácil de lo que realmente es, pero los beneficios valen la pena. Así es como puede comenzar a escribir código más limpio hoy. , que analiza un lado más práctico de la programación. Si no puede leer su propio código y entenderlo de un vistazo, ¿cómo lo hará alguien más? El código limpio es un código inodoro.
¿Con qué lucha más cuando se trata de programación? Comparte con nosotros en los comentarios a continuación!
Crédito de la imagen: SIphotography / Depositphotos