20 historias con 5 olores de código cada una son 100 olores de código, ¿verdad?
Continuemos...
No posees objetos.
TL; DR: no use mi como prefijo de nombre.
Varios tutoriales antiguos usan la palabra 'mi' como un nombre perezoso. Esto es vago y conduce a errores de contexto.
MainWindow myWindow = Application.Current.MainWindow as MainWindow;
MainWindow salesWindow = Application.Current.MainWindow as MainWindow; /* Since window is instanciated, we are currently working with a specialized window playing a special role */
Podemos decirle a nuestros linters y verificadores estáticos que busquen este prefijo y nos adviertan.
Evite usar mi . Los objetos cambian según el contexto de uso.
Foto de Michał Bożek en Unsplash
Pensando en mi experiencia de modificar código, veo que paso mucho más tiempo leyendo el código existente que escribiendo código nuevo. Si quiero que mi código sea barato, por lo tanto, debería hacerlo fácil de leer.
Kent Beck
Grandes citas de ingeniería de software
Debemos tener especial cuidado con las descripciones de errores para los usuarios (y para nosotros mismos).
TL; DR: use descripciones significativas y sugiera acciones correctivas.
Los programadores rara vez son expertos en UX.
También subestimamos el hecho de que podemos estar en ambos lados del mostrador.
alert("Cancel the appointment?", "Yes", "No"); // No consequences // Options not clear
alert("Cancel the appointment? \n" + "You will lose all the history", "Cancel Appointment", "Keep Editing"); // Consequences are clear // Choice options have context
Necesitamos leer todos los mensajes de excepción en las revisiones de código.
Necesitamos pensar en nuestros usuarios finales al generar una excepción o mostrar mensajes.
Si bien es un hecho conocido que los programadores nunca cometen errores, sigue siendo una buena idea complacer a los usuarios comprobando los errores en los puntos críticos de su programa.
Roberto D. Schneider
La ortografía y la legibilidad son muy importantes para los humanos y no importantes para las máquinas.
TL;DR: Cuida tus nombres.
Muchos de nosotros no hablamos inglés como nuestro primer idioma.
Necesitamos tener especial cuidado con nuestros textos y nombres.
Este artículo tiene un error tipográfico en su título como prueba de contexto y también un clickbait 😀
comboFeededBySupplyer = supplyer.providers();
comboFedBySupplier = supplier.providers();
Preste mucha atención a sus nombres.
Probablemente serás la persona que lea el código en unos meses.
Code Smell 48 - Código sin estándares
¿Qué es exactamente un nombre? Parte I La Búsqueda
¿Qué es exactamente un nombre? Parte II Rehabilitación
Foto de Brett Jordan en Unsplash
Dentro de cada programa grande bien escrito hay un pequeño programa bien escrito.
COCHE Hoare
¿Cuántas veces vemos nombres de argumentos perezosos?
TL; DR: nombre sus argumentos según el rol y no la posición accidental
Cuando escribimos métodos, generalmente no nos detenemos para encontrar nombres decentes.
Nunca refactorizamos lo obvio, tampoco.
class Calculator: def subtract(self, first, second): return first - second class CalculatorTest def test_multiply(): assert equals(first, second)
class Calculator: def subtract(self, minuend, subtrahend): return minuend - subtrahend class CalculatorTest def test_multiply(): assert equals(expectedValue, realValue)
Podemos advertir sobre palabras prohibidas como 'primero' y 'segundo' como nombres de argumentos.
Siempre siga la regla que sugiere el parámetro.
Nombra a tus colaboradores según el rol.
Code Smell 65 - Variables nombradas según tipos
¿Qué es exactamente un nombre? Parte II Rehabilitación
Foto de Priscilla Du Preez en Unsplash
El código fuente final es el diseño de software real.
jack reeves
GOTO fue considerado dañino hace 50 años
TL; DR: Nunca uses GoTo.
Empecé a programar en Basic.
GOTO fue fuertemente abusado allí.
Tuve que aprender programación estructurada desde cero en modo Rehab.
for x < 0 { if x > -1e-09 { goto small } z = z / x x = x + 1 } for x < 2 { if x < 1e-09 { goto small } z = z / x x = x + 1 } if x == 2 { return z } x = x - 2 p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6] q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7] return z * p / q small: if x == 0 { return Inf(1) } return z / ((1 + Euler*x) * x) }
for x < 0 { if x > -1e-09 { return small(x, z) } z = z / x x = x + 1 } for x < 2 { if x < 1e-09 { return small(x, z) } z = z / x x = x + 1 } if x == 2 { return z } x = x - 2 p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6] q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7] return z * p / q small(x, z) { if x == 0 { return Inf(1) } return z / ((1 + Euler*x) * x) } }
En idiomas compatibles con GOTO , nuestros linters pueden advertirnos contra su uso.
Reconocimos los problemas de GOTO hace unas décadas.
El problema sigue presente en lenguajes modernos como GoLang, PHP, Perl, etc.
La mayoría de los programadores afortunadamente evitan la sentencia GOTO. El próximo objetivo será considerar el uso nulo dañino.
Cortesía XKCD
Foto de Jens Johnsson en Unsplash
Es prácticamente imposible enseñar buena programación a estudiantes que han tenido una exposición previa a BASIC: como programadores potenciales, están mentalmente mutilados sin esperanza de regeneración.
Edsger Dijkstra
Grandes citas de ingeniería de software
Y eso es todo por ahora, hemos alcanzado el hito 100.
¡El próximo artículo explicará 5 olores de código más!