El término co-smell es fundamental para asegurar que el código que desarrollamos sea eficiente y comprensible. Es un concepto que se refiere a la "sensación" de que algo no está bien en el código, similar a cuando algo "huele mal". Aunque en español no tenemos un equivalente exacto, podemos decir que percibimos que algo no está correcto o puede mejorarse. Estas percepciones se desarrollan con la práctica y la experiencia, permitiéndonos identificar errores rápidamente. Vamos a explorar algunos ejemplos comunes de co-smells y cómo reconocerlos.
¿Cómo reconocemos un co-smell en el nombramiento?
Uno de los co-smells más comunes es el nombramiento inadecuado de variables, métodos o clases. Los nombres deben ser lo más descriptivos posible. En caso contrario, al leer el código, la falta de claridad en los nombres puede confundir al desarrollador y dificultar el entendimiento del flujo lógico. Si los nombres no informan correctamente sobre su función o contenido, hay una alta probabilidad de que estemos ante un co-smell.
¿Los métodos y clases largas son un indicador?
Sí, las clases y métodos demasiado extensos representan otro co-smell. Aunque no hay un estándar exacto en cuanto a la longitud, si una clase supera las 1000 o 1500 líneas de código, es una señal de alarma. Generalmente, esto indica que la clase tiene demasiadas responsabilidades que podrían dividirse en componentes más pequeños y especializados, mejorando así la comprensión y mantenimiento del código.
¿Qué ocurre con los métodos que usan muchos parámetros?
Cuando un método o función empieza a acumular muchos parámetros, puede desencadenar un co-smell. La multiplicidad de parámetros puede indicar que dentro de la función existe mucha lógica y flujos que complican su legibilidad. Si ves un método sobrecargado de parámetros, es probable que internamente haya problemas que necesitan ser evaluados y corregidos.
¿Qué son los números mágicos y cómo evitarlos?
Los "números mágicos" son valores numéricos que se encuentran directamente insertados en el código, sin una explicación clara de su propósito. Su uso se considera una mala práctica porque los desarrolladores deben realizar un análisis adicional para entender qué significan y por qué están allí. Este co-smell se puede resolver utilizando constantes con nombres descriptivos o mediante enumeraciones.
enumMenu{ Add =1, Remove =2, List =3, Exit =4}
En este ejemplo, hemos reemplazado números directos por una enumeración clara para un menú, lo que facilita la comprensión del código. Así, en lugar del número, vemos un nombre que explica la funcionalidad.
¿Cómo mejorar el código evitando co-smells?
La clave para evitar co-smells es aplicar buenas prácticas desde el inicio del desarrollo:
Nombre descriptivo: Usa nombres claros y significativos para las variables, funciones y clases.
Divide y vencerás: Si un método o clase es muy extenso, divídelo en partes más pequeñas y manejables.
Evita parámetros excesivos: Si un método necesita muchos parámetros, revisa su estructura; quizás necesite ser reorganizado o subdividido.
Asigna significados: Sustituye números mágicos por constantes o enumeraciones descriptivas.
Estos consejos no son exhaustivos, pero son un buen punto de partida. Explorar la documentación y continuar aprendiendo sobre nuevas prácticas de codificación será crucial para refinar tus habilidades. ¡El mundo del desarrollo es vasto y siempre hay algo nuevo por aprender!
Identificación de Co-Smells en C-Sharp y Soluciones Prácticas
creo que hay otras formas mas elegantes de escribir ese codigo, lo importante es que me parece que las funciones con menos de 4 parametros son mas faciles de leer.
Lo hice de esta forma, ya que usar if en un programa grande es mas optimo usar switch y ademas si la comparacion es de solo igual a, lo mejor es usar switch
<code>
TaskList=newList<string>(); int menuselected =0;do{ menuselected =ShowMainMenu();switch(menuselected){case1:ShowMenuAdd();break;case2:ShowMenuRemoveTask();break;case3:ShowMenuTaskList();break;}}while(menuselected !=4);
Si pienso que en esos casos seria mejor un switch porque estamos usando solo una comparacion igual y muchos valores a evaluar
Para evaluar code smells, usé mucho Sonarqube, como herramienta de análisis estático. Las reglas para detectar code smells (incluso otras reglas que veremos mas adelante) me ayudaron a entender y mejorar mucho la programación, vale la pena revisarlas e ir entendiéndolas.
https://rules.sonarsource.com/csharp/type/Code%20Smell
Code smell es un término utilizado en el desarrollo de software para describir signos o indicios de que puede haber problemas en el código fuente. Estos indicios no son necesariamente errores de programación o bugs, pero sugieren que el código podría beneficiarse de mejoras, refactoring o una revisión más detallada.
Nombres de variables errados: Nombres poco claros o genéricos pueden hacer que el código sea difícil de entender.
Clases o métodos largos: Clases o métodos que son excesivamente largos y realizan múltiples tareas pueden ser difíciles de entender y mantener.
Demasiados parámetros: Clases o módulos con una gran cantidad de atributos y métodos pueden indicar una falta de cohesión y responsabilidades excesivas.
Números mágicos: Se refiere a valores literales o constantes que se utilizan directamente en el código en lugar de ser asignados a variables con nombres descriptivos.
Algunos otros son:
Código duplicado: Repetición innecesaria de fragmentos de código que podrían ser reutilizados o abstraídos en funciones o clases.
Anidación excesiva de bucles o condicionales: Demasiados niveles de anidación pueden complicar el flujo del programa.
Dependencias circulares: Cuando las clases tienen dependencias circulares, puede ser un signo de un acoplamiento excesivo y una mala arquitectura.
Comentarios excesivos o inútiles: La necesidad de comentarios excesivos a menudo indica que el código no es lo suficientemente claro por sí mismo.
Código muerto: Código que no se utiliza y está presente en el repositorio, lo que puede confundir a los desarrolladores.
Al momento qué convertimos menuSelected a Enum podemos comparar Enum con Enum.
La opción que planteas también es válida al final es tratar de encontrar lo que mas convenga y que sea fácil de leer.
Algo más en términos de español, un poco más vívida la misma idea, sería: "Tu código está escrito con las patas."
o quizá:
"Tu código no tiene pies ni cabeza."
Los "code smells" (o "malos olores del código") en C# se refieren a ciertos patrones o estructuras en el código que indican posibles problemas de diseño o implementación. Estos "smells" a menudo señalan áreas donde el código podría mejorarse para tener una mejor legibilidad, mantenibilidad y eficiencia. Aquí tienes algunos "code smells" comunes en C#:
1. **Métodos largos**: Los métodos excesivamente largos pueden ser difíciles de entender, probar y mantener. Divídelos en métodos más pequeños y enfocados.
2. **Clases grandes**: Similar a los métodos largos, las clases que son demasiado grandes a menudo indican que están haciendo demasiado. Considera dividirlas en clases más pequeñas y cohesivas.
3. **Obsesión por lo primitivo**: El uso excesivo de tipos primitivos (como cadenas o enteros) en lugar de crear tipos específicos del dominio puede conducir a un código menos expresivo y menos mantenible. Crea tipos personalizados para representar conceptos del dominio.
4. **Código repetido**: El código duplicado debe evitarse ya que conlleva sobrecarga de mantenimiento y posibles errores. Refactoriza el código duplicado en métodos o clases reutilizables.
5. **Listas de parámetros largas**: Los métodos con un gran número de parámetros pueden ser difíciles de usar y entender. Considera usar objetos de parámetros o dividir el método en otros más pequeños y enfocados.
6. **Intimidad inapropiada**: Las clases que están demasiado acopladas violan el principio de encapsulación y pueden ser difíciles de mantener y probar. Reduce las dependencias entre clases usando interfaces, inyección de dependencias u otros patrones de diseño.
7. **Nomenclatura inconsistente**: Las convenciones de nomenclatura inconsistentes hacen que el código sea más difícil de entender. Usa una nomenclatura clara y consistente en todo tu código.
8. **Envidia de características**: Cuando un método accede a los datos de otra clase más que a los suyos propios, puede indicar que el método pertenece a la otra clase. Considera mover el método a la clase que posee los datos.
9. **Grandes instrucciones SWITCH o IF-ELSE**: Las instrucciones switch y las cadenas if-else largas pueden ser difíciles de mantener y extender. Considera usar polimorfismo, el patrón de estrategia o tablas de búsqueda para manejar estos casos de manera más elegante.
10. **Grupos de datos**: Cuando grupos de campos de datos se pasan frecuentemente juntos, puede indicar que deberían estar juntos en su propia clase. Crea una nueva clase para encapsular campos de datos relacionados.
11. **Clases Dios**: Clases que saben o hacen demasiado, violando el Principio de Responsabilidad Única. Refactoriza estas clases en otras más pequeñas y enfocadas.
12. **Complejidad ciclomática**: Alta complejidad ciclomática en los métodos puede indicar una lógica demasiado compleja que es difícil de entender y probar. Refactoriza estos métodos en piezas más pequeñas y manejables.
Al identificar y abordar estos "code smells", puedes mejorar la calidad, legibilidad y mantenibilidad de tu base de código en C#.
Hay unos libros recomendados para aprender estas buenas prácticas "The clean code" y de "Clean Coder" escritos por Bob Martin, conocido también Como Uncle Bob, y tienen acumulados muchos años de desarrollo y buenos prácticas