Los olores a código son un clásico.

Huele porque es probable que haya muchos casos en los que podría editarse o mejorarse.

La mayoría de estos olores son solo indicios de algo que podría estar mal. Por lo tanto, no es necesario que se arreglen per se... (Sin embargo, debe investigarlo).

Olores de código anteriores

Puedes encontrar todos los olores del código anterior (Parte i - XXIX) aquí

Continuemos...

Code Smell 146 - Comentarios de Getter

Los comentarios son un código Olor. Los captadores son otro olor a código. ¿Adivina qué?

TL; DR: No use captadores. No comentes captadores

Problemas

• Comentarios abusadores
• Legibilidad
• captadores

Soluciones

1. Eliminar comentarios captadores
2. Quitar captadores

Contexto

Hace unas décadas, solíamos comentar todos los métodos. Incluso los triviales.

El comentario debe describir solo una decisión crítica de diseño.

Código de muestra

Equivocado

 pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } }

Derecho

 pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } }

Detección

• [x] Semiautomático

Podemos detectar si un método es getter y tiene un comentario.

Excepciones

La función necesita un comentario, que accidentalmente es un captador y el comentario está relacionado con una decisión de diseño.

Etiquetas

• Comentarios

Conclusión

No comentes captadores.

No agregan ningún valor real e inflan su código.

Relaciones

Code Smell 05 - Abusadores de comentarios

Code Smell 68 - Captadores

Code Smell 01 - Modelos anémicos

Créditos

Foto de Reimond de Zuñiga en Unsplash

El código debe ser notablemente expresivo para evitar la mayoría de los comentarios. Habrá algunas excepciones, pero deberíamos ver los comentarios como una "falta de expresión" hasta que se demuestre lo contrario.

Roberto Martín

Grandes citas de ingeniería de software

Code Smell 147 - Demasiados métodos

Las clases de utilidad son geniales para recopilar protocolo.

TL; DR: no agregue protocolo accidental a sus clases

Problemas

• Legibilidad
• Violación de responsabilidad única
• mala cohesión
• alto acoplamiento
• Reutilización baja

Soluciones

1. rompe tu clase
2. Extraer clase

Refactorizaciones

Refactorización 007 - Extraer clase

Contexto

Tendemos a poner un protocolo en la primera clase que encontramos.

Eso no es un problema.

Solo tenemos que refactorizar.

Código de muestra

Equivocado

 public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } }

Derecho

 public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } }

Detección

• [x] Automático

La mayoría de los linters cuentan los métodos y nos advierten.

Relaciones

Code Smell 124 - Cambio divergente

Code Smell 143 - Grupos de datos

Code Smell 94 - Demasiadas importaciones

Code Smell 22 - Ayudantes

Code Smell 34 - Demasiados atributos

Más información

Gurú de la refactorización

Etiquetas

• Cohesión
• hinchados

Conclusión

Dividir clases y protocolo es una buena práctica para favorecer objetos pequeños y reutilizables.

Créditos

Foto de Marcin Simonides en Unsplash

No hay código tan grande, retorcido o complejo que el mantenimiento no pueda empeorar.

Gerald M Weinberg

Código olor 148 - tareas pendientes

Compramos deuda para nuestro futuro yo. Es tiempo de venganza.

TL; DR: No deje TODO en su código. ¡Arreglalos!

Problemas

• Deuda técnica
• Legibilidad
• Falta de confianza

Soluciones

1. Arregla tus TODO

Contexto

Nos encontramos con TODO en nuestro código. Los contamos.

Rara vez lo abordamos.

Empezamos con la deuda técnica.

Luego pagamos la deuda + los intereses.

Unos meses después, pagamos más intereses que la deuda original.

Código de muestra

Equivocado

 public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { // TODO: Implement close door and cover it } }

Derecho

 public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { this.isOpened = false; } }

Detección

• [x] Automático

Podemos contar TODOs.

Etiquetas

• Deuda técnica

Conclusión

Podemos contar TODOs.

La mayoría de los linters lo hacen.

Necesitamos la política para reducirlos.

Si estamos usando TDD, escribimos el código que falta de inmediato.

En este contexto, las TODO solo son válidas cuando se realiza un desarrollo Primero en profundidad para recordar los caminos abiertos para visitar.

Más información

• ¿Deberías poner ToDos?
• Teoría de las ventanas rotas

Créditos

Foto de Eden Constantino en Unsplash

Después de terminar el primer 90 % de un proyecto, debe terminar el otro 90 %.

miguel abrash

Code Smell 149 - Encadenamiento opcional

Nuestro código es más robusto y legible. Pero escondemos NULL debajo de la alfombra.

TL; DR: Evite Nulos e indefinidos. Si los evita, nunca necesitará Opcionales.

Problemas

• nulos
• SI Contaminante

Soluciones

1. Quitar nulos
2. Tratar con indefinido

Contexto

Encadenamiento opcional, opcionales, coalescencia y muchas otras soluciones nos ayudan a lidiar con los infames nulos.

No hay necesidad de usarlos una vez que nuestro código es maduro, robusto y sin valores nulos.

Código de muestra

Equivocado

 const user = { name: 'Hacker' }; if (user?.credentials?.notExpired) { user.login(); } user.functionDefinedOrNot?.(); // Seems compact but it is hacky and has lots // of potential NULLs and Undefined

Derecho

 function login() {} const user = { name: 'Hacker', credentials: { expired: false } }; if (!user.credentials.expired) { login(); } // Also compact // User is a real user or a polymorphic NullUser // Credentials are always defined. // Can be an instance of InvalidCredentials // Assuming we eliminated nulls from our code if (user.functionDefinedOrNot !== undefined) { functionDefinedOrNot(); } // This is also wrong. // Explicit undefined checks are yet another code smell

Detección

• [x] Automático

Esta es una función de idioma .

Podemos detectarlo y eliminarlo.

Etiquetas

• Nulo

Conclusión

Muchos desarrolladores se sienten seguros contaminando el código con transacciones nulas.

De hecho, esto es más seguro que no tratar los NULL en absoluto.

Los valores nulos , verdaderos y falsos también son olores de código.

Necesitamos apuntar más alto y hacer un código más limpio.

Lo bueno : elimine todos los valores nulos de su código.

Lo malo : usa el encadenamiento opcional.

Lo feo : no tratar nulos en absoluto.

Relaciones

Code Smell 145 - Truco de cortocircuito

Código Olor 12 - Nulo

Code Smell 69 - Big Bang (Castings ridículos de JavaScript)

Más información

• Referencia de encadenamiento opcional

Null: El error del billón de dólares

Cómo deshacerse de los IF molestos para siempre

¿QUÉ?

Créditos

Foto de engin akyurt en Unsplash

El que pelea con monstruos debe tener cuidado de no convertirse en un monstruo. Y si miras por mucho tiempo a un abismo, el abismo también te mira a ti.

Nietzsche

Code Smell 150 - Comparación igual

Cada desarrollador compara los atributos por igual. Están equivocados.

TL; DR: No exporte y compare, solo compare.

Problemas

• Rotura de encapsulación
• Duplicación de código
• Violación de ocultación de información
• Violación del antropomorfismo

Soluciones

1. Ocultar la comparación en un solo método

Contexto

La comparación de atributos se usa mucho en nuestro código.

Tenemos que centrarnos en el comportamiento y las responsabilidades.

Es responsabilidad de un objeto compararlo con otros objetos. No el nuestro.

Los optimizadores prematuros nos dirán que esto tiene menos rendimiento.

Deberíamos pedirles evidencia real y contrastar la solución más mantenible.

Código de muestra

Equivocado

 if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive

Derecho

 if (address.isAtStreet('Broad Street') { } // ... if (location.isAtStreet('Bourbon St') { } // 15000 usages in a big system function isAtStreet(street) { // We can change Comparisons to // case sensitive in just one place. }

Detección

• [x] Semiautomático

Podemos detectar comparaciones de atributos utilizando árboles de sintaxis.

Puede haber buenos usos para tipos primitivos como con muchos otros olores.

Etiquetas

• Encapsulación

Conclusión

Necesitamos poner las responsabilidades en un solo lugar.

Comparar es uno de ellos.

Si algunas de nuestras reglas comerciales cambian, debemos cambiar un solo punto .

Relaciones

Code Smell 63 - Envidia de características

Code Smell 101 - Comparación con booleanos

Code Smell 122 - Obsesión primitiva

Créditos

Foto de Piret Ilver en Unsplash

El comportamiento es lo más importante del software. Es de lo que dependen los usuarios. A los usuarios les gusta cuando agregamos comportamiento (siempre que sea lo que realmente querían), pero si cambiamos o eliminamos el comportamiento del que dependen (introducimos errores), dejan de confiar en nosotros.

Michael plumas

Artículo siguiente: 5 olores de código más.