Las personas, por su naturaleza, son propensas a cometer errores. Sin embargo, se pueden evitar muchas deficiencias específicas de los desarrolladores. Si un programador puede deshacerse de los errores comunes que se analizarán en este artículo, podrá escribir un código mejor y más limpio.
La eliminación de fallas en el código beneficiará no solo a aquellos que se deshacen de ellos, sino también a aquellos programadores que tienen que leer este código. Como resultado, podemos decir que aquellos que trabajan en equipo y se esfuerzan por mejorar su código hacen esto no solo por ellos mismos, sino también por aquellos con quienes trabajan.
Aquí hay algunos defectos comunes que un programador debe evitar.
1. Demasiadas acciones en la función
De acuerdo con el principio de responsabilidad exclusiva, una función debe ser responsable solo del desempeño de cualquier operación. Y esto debería ser solo una operación. Vi demasiadas funciones que realizan la carga, el procesamiento y la presentación de ciertos datos. Se cree que la implementación de tales acciones se distribuye mejor entre varias funciones. Una función carga datos, otra procesa, la tercera es responsable de su presentación.
La razón de la importancia de escribir funciones que se centren en resolver un solo problema es que este enfoque hace que el código sea más confiable. Supongamos que en el caso anterior, los datos se cargan desde una determinada API. Si esta API cambia, por ejemplo, si se lanza una nueva versión, es muy probable que toda la función deje de funcionar. El código que carga los datos cargará algo incorrecto, esto afectará el procesamiento y la presentación de los datos. Para resolver el problema, primero tendrá que encontrarlo, descubrir qué falló y luego editar el código de una función grande. Si la carga, el procesamiento y la presentación de datos se dividen en varias funciones, resolver estos problemas será mucho más fácil.
2. El proyecto ha comentado el código
Todos vieron el código, cuyos fragmentos grandes, por ejemplo, que contienen ciertas funciones, están comentados. Sin embargo, nadie sabe por qué estos fragmentos aún no se eliminan de la base del código. Y nadie sabe si estas piezas de código funcionarán si no están comentadas. Pero al mismo tiempo no se eliminan. Y necesitas eliminarlos. La razón por la que este código contamina proyectos es porque todos sugieren que alguien podría necesitar este código.
Dichos fragmentos de código deberían simplemente eliminarse. Y si en la última versión del código estos fragmentos remotos no están presentes, y al mismo tiempo alguien realmente los necesita, se pueden encontrar en el sistema de control de versiones. Observo que esta es solo mi opinión sobre este tema.
3. Nombres de variables incorrectos
Una vez escribí
un artículo que presentaba reglas simples para seleccionar buenos nombres de variables. Los nombres de variables cualitativas son extremadamente importantes. El hecho es que los programadores generalmente no trabajan en proyectos solos. Sus colegas necesitan entender el código que escriben. Los nombres de variables amigables ayudan a mejorar la percepción del código de otra persona.
Repito lo que dije en el material anterior: "Elegir buenos nombres de variables lleva tiempo, pero ahorra más tiempo del que lleva".
4. "Números mágicos" y cuerdas
Si continuamos nuestras discusiones sobre el problema de los nombres oscuros de las variables, podemos llegar a la idea de usar ciertos valores en el programa, "números mágicos" o cadenas que no tienen ningún nombre y no están escritas en ninguna variable.
Puede aprender de
Wikipedia que los "números mágicos" se llaman malas prácticas de programación cuando se encuentra un valor numérico en el texto fuente y no es obvio lo que significa.
Eche un vistazo al siguiente ejemplo de código:
for ($i = 1; $i <= 52; $i++) { ... }
Aquí el valor
52 es el "número mágico". Nadie sabe por qué este es exactamente el número 52, y qué significa. ¿Por qué 52? ¿Por qué no 64? Tal vez esta es la cantidad de semanas en un año?
Este código será mucho más claro si lo reescribe así:
$cardDeckSize = 52; for ($i = 1; $i <= $cardDeckSize; $i++) { ... }
Ahora cualquiera entenderá que en un ciclo pasamos por una baraja de cartas. Esto indica a otros desarrolladores la esencia de lo que está sucediendo, ayuda a comprender el contexto de la acción que se realiza. Este enfoque, además, simplifica enormemente el cambio de este valor, ya que, si se usa en diferentes lugares del programa, se establece solo en un lugar en el código.
Lo mismo se aplica al trabajo con cadenas:
if (userPasswordIsValid($user, "6yP4cZ".$password)) { ... }
¿Qué es este
6yP4cZ ? Parece un conjunto de caracteres aleatorio.
Reescribimos esto:
$salt = "6yP4cZ"; if (userPasswordIsValid($user, $salt.$password)) { ... }
Pero ahora todo está mucho más claro.
5. Formato de código inexacto
El formato de código desordenado es una "enfermedad" para los programadores novatos. Muchos desarrolladores con cierta experiencia tienden a asentir afirmativamente cuando se les pregunta si conocen a un probador o un científico de datos que no formatea bien el código. La razón de esto es la falta de experiencia. Las únicas excepciones son aquellos programadores que usan un lenguaje como Python, en el que el formato del código afecta la ejecución del programa.
Una de las formas más comunes de resolver este problema es usar un linter. Todos los IDE modernos, además, admiten la capacidad de formatear automáticamente el código. A veces, esta funcionalidad se implementa mediante complementos que necesita instalar usted mismo, y a veces se incluye en las características IDE estándar.
6. Valores codificados en código
Si los valores están codificados en los programas, esto significa que los datos se incrustan directamente en el código fuente o en otros objetos similares. Lo contrario de este enfoque es obtener datos de fuentes externas o generarlos durante la ejecución del programa.
Los valores fijos no permiten una fácil configuración del programa. Son, por así decirlo, "tallados en piedra". Esto se considera un antipatrón o, como mínimo, indica problemas obvios en el código.
Muy a menudo, las contraseñas y las rutas de archivo están codificadas. Lo hacen por una variedad de razones, a veces incluso pueden estar justificadas.
Por ejemplo, se pueden ver muchos valores codificados en algunos ejemplos de código responsable de la autenticación en servicios externos o API. Es mejor no hacer eso.
Si alguien notó el uso frecuente de valores codificados, debería evaluar críticamente su trabajo. El hecho es que, por lo general, el uso de tales valores no es la mejor manera de resolver ciertos problemas.
Estimados lectores! ¿Qué deficiencias en el código ha encontrado?
