Foto de Filipe Resmini en Unsplash
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. No son obligatorios fijos per se... (Deberías investigarlo).
Continuemos...
No haga pruebas débiles para crear una falsa sensación de cobertura.
square = Square(5) assert square.area() != 0 # This will lead to false negatives since it is too vague
square = Square(5) assert square.area() = 25 # Assertion should be precise
Con las técnicas de Mutation Testing podemos encontrar estos errores en nuestras pruebas.
Deberíamos usar técnicas de desarrollo como TDD que solicitan casos comerciales concretos y hacen afirmaciones concretas basadas en nuestro dominio.
Code Smell 30 - Burlarse del negocio
Code Smell 52 - Pruebas frágiles
Este olor fue inspirado por @Mario Cervera y usado con su permiso .
Las marcas de tiempo son ampliamente utilizadas. Tienen una autoridad emisora central y no retroceden, ¿verdad?
# using time module import time # ts stores the time in seconds ts1 = time.time() ts2 = time.time() #might be the same!!
numbers = range(1, 100000) #create a sequence of numbers and use them with a hotspot #or sequence = nextNumber()
Las marcas de tiempo son muy populares en muchos idiomas y son omnipresentes.
Necesitamos usarlos solo para modelar... marcas de tiempo.
Este olor se inspiró en una falla reciente del software Ingenuity .
Si no seguimos las reglas de MAPPER y las secuencias de modelos con el tiempo, nos enfrentaremos a problemas.
Afortunadamente, Ingenuity es un vehículo autónomo sofisticado y tiene un sólido software de aterrizaje a prueba de fallas.
Este video describe la falla.
https://www.youtube.com/watch?v=6IoMiwxL2wU
Código olor 39 - nueva fecha ()
Code Smell 71 - Flotadores mágicos disfrazados de decimales
jon bentley
Procesar un algoritmo como una secuencia de devoluciones de llamadas anidadas no es inteligente.
TL; DR: no procese las llamadas en forma de devolución de llamada. Escribe una secuencia.
var fs = require('fs'); var fileWithData = '/hello.world'; fs.readFile(fileWithData, 'utf8', function(err, txt) { if (err) return console.log(err); txt = txt + '\n' + 'Add Data!'; fs.writeFile(fileWithData, txt, function(err) { if(err) return console.log(err); console.log('Information added'); }); });
var fs = require('fs'); function logTextWasAdded(err) { if(err) return console.log(err); console.log('Information added'); }; function addData(error, actualText) { if (error) return console.log(error); actualText = actualText + '\n' + 'Add data'; fs.writeFile(fileWithData, actualText, logTextWasAdded); } var fileWithData = 'hello.world'; fs.readFile(fileWithData, 'utf8', addData);
Este problema brilla a simple vista. Muchos linters pueden detectar esta complejidad y advertirnos.
Callback Hell es un problema muy común en los lenguajes de programación con futuros o promesas.
Las devoluciones de llamada se agregan de forma incremental. No hay mucho desorden al principio.
La complejidad sin refactorización los hace difíciles de leer y depurar.
Code Smell 06 - Programador demasiado inteligente
Código Olor 102 - Código de flecha
Si ya se usa un nombre, siempre podemos prefijarlo con 'the'.
TL; DR: no anteponga sus variables.
var result; result = getSomeResult(); var theResult; theResult = getSomeResult();
var averageSalary; averageSalary = calculateAverageSalary(); //.. var averageSalaryWithRaises; averageSalaryWithRaises = calculateAverageSalary();
Al igual que con muchas de nuestras convenciones de nomenclatura, podemos indicar a nuestros linters que prohíban nombres como theXxx... .
Utilice siempre nombres que revelen la intención.
Si sus nombres chocan, use nombres locales, extraiga sus métodos y evite los prefijos 'the'.
Code Smell 38 - Nombres abstractos
Foto de Josue Michel en Unsplash
Una diferencia entre un programador inteligente y un programador profesional es que el profesional entiende que la claridad es el rey. Los profesionales usan sus poderes para el bien y escriben código que otros pueden entender.
Roberto C. Martín
Las excepciones son una excelente manera de separar el camino feliz del camino problemático. Pero tendemos a complicar demasiado nuestras soluciones.
try { transaction.commit(); } catch (e) { logerror(e); if (e instanceOf DBError){ try { transaction.rollback(); } catch (e) { doMoreLoggingRollbackFailed(e); } } } //Nested Try catchs //Exception cases are //more important than happy path //We use exceptions as control flow
try { transaction.commit(); } catch (transactionError) { this.withTransactionErrorDo( transationError, transaction); } //transaction error policy is not defined in this function //so we don't have repeated code //code is more readable //It is up to the transaction //and the error to decide what to do
Podemos detectar este olor utilizando árboles de análisis.
No abuse de las excepciones, no cree clases de excepción que nadie detectará nunca y no esté preparado para todos los casos (a menos que tenga un buen escenario real con una prueba de cobertura).
El camino feliz siempre debe ser más importante que los casos de excepción.
Code Smell 73 - Excepciones para casos esperados
Code Smell 26 - Excepciones Contaminantes
Foto de David Clode en Unsplash
Gracias a @Rodrigo por su inspiración
Carolina Szczur
Y eso es todo por ahora…
¡El próximo artículo explicará 5 olores de código más!