¡Tu código puede oler! Como arreglarlo

UNA código de olor 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 el olor de un código como un signo que sugiere que una sección del código debe ser refactorizada. No es que el código tenga errores o no sea funcional, muchas veces, el código maloliente funciona bien, pero el código maloliente a menudo es difícil de mantener y extender, lo que puede llevar a problemas técnicos (especialmente en proyectos más grandes).

En este artículo, resaltaremos 10 de los olores de código más comunes, qué buscar y cómo desodorizarlos. Si eres un programador nuevo Cómo aprender a programar sin todo el estrés Cómo aprender a programar sin todo el estrés Tal vez hayas decidido dedicarte a la programación, ya sea para una carrera o simplemente como pasatiempo. ¡Genial! Pero tal vez estás empezando a sentirte abrumado. No muy bien. Aquí hay ayuda para facilitar su viaje. Lea más, evite estos y su código será notablemente mejor!

1. Acoplamiento apretado

El problema
El acoplamiento apretado se produce cuando dos objetos dependen tanto 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 quisiera conducir un automóvil en lugar de una bicicleta para su viaje diario? Tendría que ingresar a la clase Trabajador y reemplazar todo el código relacionado con la Bicicleta por el código relacionado con el Coche. Es desordenado y propenso a errores..

La solución
Puedes aflojar el acoplamiento añadiendo una capa de abstracción. En este caso, la clase Trabajador no solo quiere conducir Bicicletas, sino también Autos, y quizás Camiones, posiblemente incluso Scooters. Estos son todos los vehículos, ¿no? Así que cree una interfaz de Vehículo, que le permite insertar y reemplazar diferentes tipos de Vehículos como desee:

trabajador de clase vehículo de vehículo; cambio de void públicoVehículo (Vehículo v) vehículo = v;  public void commute () vehicle.drive ();  interfaz vehículo void drive ();  clase bicicleta implementa Vehículo public void drive ()  clase Coche implementa Vehículo public void drive () 

2. Dios objetos

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 este para datos (acoplamiento apretado). En segundo lugar, la estructura general del programa se vuelve confusa a medida que todo se atasca 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 esos grupos en objetos. Si tienes un objeto de Dios, puede ser mejor como una composición de muchos objetos más pequeños.

Por ejemplo, suponga que tiene una clase de usuario monstruosa:

usuario de la clase nombre de usuario de la 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 () devolver nombre de usuario;  public void setUsername (String u) username = u; 

Podrías convertirlo en una composición de lo siguiente:

clase Usuario Credenciales credenciales; Perfil perfil;… credenciales de la clase nombre de usuario de la 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 tendrá que rastrear una clase de Usuario masiva porque la clase Credenciales es más manejable!

3. Funciones largas

El problema
Una función larga es exactamente lo que suena: una función que ha crecido demasiado. Si bien no hay un número específico para cuántas líneas de código es “demasiado largo” para una función, es una de esas cosas donde la conoces cuando la ves. Es prácticamente una versión de alcance más estricto 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 uno y sería mejor que el código dividiera esa función en dos o más funciones diferentes. A diferencia del “Funciones largas” olor del 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 cubren responsabilidades separadas.

5. Identificadores mal nombrados

El problema
Nombres de variables de una o dos letras. Nombres de función no descriptivos. Nombres de clase demasiado adornados. Marcar nombres de variables con su tipo (por ejemplo, b_isCounted para una variable booleana). Y lo peor de todo, mezclando diferentes esquemas de nombres a lo largo de un solo código base. Todo esto resulta en un código difícil de leer, difícil de entender y de mantener..

La solución
Elegir buenos nombres para variables, funciones y clases es una habilidad que se aprende con dificultad. Si se está uniendo a un proyecto existente, combínelo y vea cómo se nombran los identificadores existentes. Si hay una guía de estilo, memorízala y adhiérete a ella. Para nuevos proyectos, considera formar tu propia guía de estilo y apégate a ella.

En general, los nombres de las variables deben ser cortos pero descriptivos. Los nombres de 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 abarrotar demasiadas palabras. Lo mismo ocurre con los nombres de clase.

6. números mágicos

El problema
Estás navegando a través de un código que (con suerte) alguien más escribió y ves algunos números codificados. Tal vez sean 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 cue.

La solución
Al escribir código, estos llamados “números magicos” Debe evitarse a toda costa. Los números codificados tienen sentido en el momento en que se escriben, pero pueden perder todo el significado rápidamente, 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 los números mágicos en variables constantes (para cálculos) o enumeración (para sentencias condicionales y sentencias 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 los cambios de buggy.

7. Anidación profunda

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 tienen un buen nombre) y aún más difícil de modificar.

La solución
Si se encuentra escribiendo un ciclo doble, triple o incluso cuádruple, entonces su código puede estar intentando alejarse demasiado de sí mismo para encontrar datos. En su lugar, proporcione una forma para que los datos se soliciten 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, los nidos profundos 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, es posible que desee implementar un patrón de estrategia o máquina de estado.

El anidamiento profundo es particularmente frecuente entre los programadores de juegos inexpertos. 5 Software de desarrollo de juegos gratuito. Herramientas para crear tus propios juegos. 5 Software de desarrollo de juegos gratis. Herramientas para hacer tus propios juegos. hoy. Lee mas !

8. Excepciones no manejadas

El problema
Las excepciones son poderosas pero fácilmente abusadas. Los programadores perezosos que usan incorrectamente las declaraciones de lanzamiento-captura pueden hacer que la depuración sea exponencialmente más difícil, si no imposible. Por ejemplo, ignorando o enterrando excepciones capturadas..

La solución
En lugar de ignorar o enterrar las excepciones capturadas, 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, prefiere atrapar 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 Utilízalos, y errores comunes para evitar. Lee mas .

9. Código duplicado

El problema
Usted ejecuta la misma lógica exacta en múltiples áreas no relacionadas de su programa. Más tarde, se dará 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 primordial para convertirse en una función. Por ejemplo, digamos que estás desarrollando una aplicación de chat y escribes esto:

String queryUsername = getSomeUsername (); boolean isUserOnline = false; para (String username: onlineUsers) if (username.equals (queryUsername)) isUserOnline = true;  if (isUserOnline) …

En algún otro lugar del código, te das cuenta de que necesitas realizar el mismo “es este usuario en línea?” comprobar. En lugar de copiar y pegar el bucle, puede extraerlo en una función:

public boolean isUserOnline (String queryUsername) para (String username: onlineUsers) if (username.equals (queryUsername)) return true;   falso retorno; 

Ahora, en cualquier lugar de su código, puede usar la verificación isUserOnline (). Si alguna vez necesitas modificar esta lógica, puedes modificar el método y se aplicará en todos los lugares a los que se llama.

10. Falta de comentarios.

El problema
El código no tiene absolutamente ningún comentario en ninguna parte. No hay bloques de documentación para funciones, no hay descripciones generales de uso para las clases, no hay 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 ingles.

La solución
El objetivo de una base de código fácil de mantener debe ser un código escrito lo suficientemente bien como para que no lo haga. necesitar Comentarios, pero todavía los tiene. Y al escribir comentarios, apunta a comentarios que expliquen. por qué existe un fragmento de código en lugar de explicar qué esta haciendo Los comentarios son buenos para el alma y la cordura. No los descuides.

Cómo escribir código que no huele

Por más obvio que parezca, la mayoría de los olores de código surgen de un malentendido o descuido de los buenos principios y patrones de programación. 10 Principios básicos de programación que todo programador debe seguir. 10 Principios básicos de programación que debe seguir cada programador. trabajando en tu software. Para ello, aquí hay varios principios de programación para ayudarlo a limpiar su acto. Lee mas . Por ejemplo, una adhesión sólida al principio DRY elimina la mayoría de la duplicación de código, mientras que el dominio del principio de responsabilidad única hace que sea casi imposible crear objetos monstruosos de Dios..

También recomendamos leer nuestro artículo sobre cómo escribir el código 10 de limpiador Consejos para escribir el código de Cleaner & Better 10 Consejos para escribir el código de Cleaner & Better El código limpio de la escritura parece más fácil de lo que realmente es, pero los beneficios valen la pena. Aquí es cómo puedes comenzar a escribir un código más limpio hoy. Leer más, que mira a 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é luchas más cuando se trata de programación? Comparte con nosotros abajo en los comentarios a continuación.!

Crédito de la imagen: SIphotography / Depositphotos

Explorar más sobre: ​​Programación.