Estaba programando una función en JavaScript, y la tenía que mandar a llamar en otros archivos, sin embargo, me di cuenta que cada vez que llamaba a esa función, era difícil acordarme de los parámetros.
Empezamos a programar sin saber las buenas prácticas, y así lo hacemos durante mucho tiempo, pensando que nuestro código es de calidad.
Pero no te preocupes, es algo que le pasa hasta los programadores más avanzados.
¿Qué son los parámetros?
Los parámetros, o también conocidos como argumentos, son los que están a la espera de obtener un valor desde donde se llame la función que las contiene.
Sí, son esas palabras que van dentro de los paréntesis de una función:
Es difícil recordar el tipo de dato que espera cada parámetro.
También es complicado recordar el orden de los mismos.
Los puntos anteriores solo te quitarán tiempo, tiempo valioso que podrías usar para programar, y tu código no será de calidad.
¡No hagas lo que yo hice!
Sólo usa 3 o 4 parámetros
Un día estaba leyendo el libro JavaScript: The Good Parts, y encontré una buena práctica, ésta decía que usar más de 3 o 4 parámetros en una función era una mala práctica.
Y la solución que presentaba el autor, era que si necesitabas usar más de 3 o 4 parámetros, éstos los pasaras a través de un objeto; es decir:
Es más legible, ¿no crees? De 8 parámetros, ahora tenemos 2.
Pero, ¡Ojo!, no porque yo esté usando JavaScript aquí, no significa que no funcione en otros lenguajes de programación. 😉
¿Qué ventajas obtienes?
Darle este tipo de soluciones a tu código, representa un gran avance a tu código, estás escribiendo código de calidad.
Además, te está aportando lo siguiente:
Código más legible.
El código se vuelve más corto.
Y ya no tenemos que acordarnos del orden de los parámetros.
¡Esto es lo que deberías estar haciendo en cada uno de tus desarrollos!
Uno de tantos code smells
El problema anterior es clasificado como un “code smell” (hediondez del código), y éste termino se refiere a que una parte del código tiene alguna deficiencia y que a la larga, ralentizará el sistema que estás desarrollando.
¿Quieres ver la cantidad de code smells que existen? Los puedes encontrar en este enlace.
Si te pones a solucionar todos estos code smells, no solo estás “solucionando”, si no que estarás “refactorizando“, y te sentirás como el Refactor Man:
El término “refactorización” no significa agregar código nuevo, se refiere a mejorar tu código, convertir ese código revuelto a código simple.
Tras ver todo esto, ¿estás decidido a programar código de calidad?
Referencias
Douglas Crockford. (2008). Chapter 5: Inheritance. Object Specifiers. JavaScript: The Good Parts. (p. 50).
Cuando estás aprendiendo a programar, solo piensas en aprender las sintaxis del lenguaje de programación, funciones, propiedades, etc, pero creo que nadie nunca ha pensado en escoger la tipografía correcta desde un principio.
Y no digo que esté mal, si no que, nosotros los programadores, pasamos la mayor parte del tiempo leyendo código que escribiéndolo; por lo tanto, debemos tener una tipografía que sea completamente legible. Una tipografía que no nos canse la vista.
Otro factor a tomar en cuenta al momento de programar, es el nombramiento, el cual te lo explico en este post.
¿Qué es una tipografía?
También conocidas como las fuentes o tipos de letras que están instaladas dentro de nuestra computadora; claro, hablando a nivel de informática.
Sabemos de ellas gracias a las herramientas de ofimática, como Microsoft Office Word, Google Docs, etc; y por lo regular, éstas herramientas solo contienen las tipografías por default del sistema operativo donde estemos.
Sin embargo, podemos descargar e instalar tipografías de terceros en nuestra computadora, a continuación una lista de sitios web para descargar tipografías de cualquier tipo:
No cualquier tipografía debería utilizarse para programar. Las tipografías que deberías usar en tu editor de texto, deben:
Ser legibles.
Tener caracteres distinguibles. Por ejemplo: Que el 1 (uno) sea distinto que la l (ele). Tal vez aquí se vea igual, pero, ¿entiendes el punto, verdad?
Los caracteres deben tener buen espacio entre cada uno.
Tengan disponibles caracteres especiales, como “<>$&/?=”, etc. Esos caracteres que a veces necesitamos para realizar alguna comparación u operación.
Mi recomendación
He probado distintas tipografías a lo largo de mi carrera como programador, y las siguientes tipografías que les voy a mostrar me han ayudado mucho al momento de programar, y esas son:
Aparentemente se ven igual, pero no, hay ligeros cambios entre ciertas letras, por ejemplo, la letra “g”.
Tu vista no se cansará si usas al menos una de esas tres tipografías que he mencionado.
Conclusión
Como dije anteriormente, los comentarios que aquí he expresado son de mi humilde opinión, no te estoy obligando a usarlas.
Si tú programas con otro tipo de tipografía y te sientes a gusto con ella, quédate con ella; pero recuerda, el probar no cuesta nada.
Y dime, ¿usas alguna otra fuente que no haya mencionado y estás orgulloso de ella? Compártela en los comentarios para que los demás podamos probarla. 🙂
Probablemente seas nuevo en el mundo de la programación y estés leyendo un libro, tutorial o guía sobre programación; desde ese momento, ¿qué es lo que haces? Estás leyendo en vez de estar escribiendo. Por lo tanto, es muy importante que el nombramiento de las cosas que otros programadores y tú escriban, estén bien escritas.
Y cuando digo “cosas“, me refiero a tus variables, funciones, parámetros e incluso comentarios. Éstos deben ser legibles y dar a entender lo que está haciendo la variable o función, si no lo son, perderás mucho tiempo leyendo el código.
Los programadores pasamos más tiempo leyendo código que escribiéndolo.
El problema del mal nombramiento de las cosas
Si el nombramiento de las cosas no son legibles y mucho menos entendibles, te podrás ver afectado a futuro. A continuación, te muestro los puntos que probablemente enfrentarás si no nombras bien las cosas.
Tu código no:
Será legible.
Podrá ser entendido ni por ti, ni por otros programadores.
Será escalable; es decir, se te dificultará agregar y/o actualizar el código.
Y la peor de todas, tal vez te tengas que ver obligado a cambiar todo el código.
Escribe tu código en inglés
¿Inglés? ¡Estás loco Roel, no me llevo con eso!
No estoy loco, solo que mayormente la documentación de las librerías y frameworks están escritas en inglés; pocas veces se encuentra en español.
Además, nunca sabes quién leerá tu código.
Por ejemplo: Estás en una empresa escribiendo tu código en español, pero el administrador del proyecto te dice que necesita que le envíes tu código a su amigo americano. ¡Huy, problemas!
Le comentas la situación al administrador del proyecto, y lamentablemente te dice que escribas tu código en inglés. ¡Tristeza! Tienes que volver a escribir el código.
¿Ya ves? Tu código lo podría leer alguien en la India, Estados Unidos, Dinamarca, etc.
No programes para ti, programa para los demás
Te pongo un ejemplo; tu has escrito el siguiente código:
Y lo tienes que enviar al administrador del proyecto para que revise tu código, él va leyendo las variables y se encuentra con la variable:
$stuff, la cual contiene una colección de frutas. Bueno, su primer pregunta es, ¿por qué la variable $stuff no se llama $fruits? No concuerda con su contenido.
Después se encuentra con la variable $x, la cual es igual a apple. ¿Es enserio? —Se pregunta. Él pensó que la variable $x contenía el valor de una coordenada en el eje X.
¿Ves que ahora es más fácil de entender a qué se refiere cada variable? Pero el chiste no es escribir de nuevo el código, eso solo te ha quitado tu valioso tiempo.
Siempre escribe bien desde el principio.
Tal vez estos ejemplos sean algo simples y muy ilógicos, pero creanme, me he encontrado con estos casos, y ustedes también lo harán y se frustrarán.
Tus palabras deben ser claras, no uses abreviaciones
Para que lo anterior funcione, debes evitar escribir abreviaciones y las palabras de las acciones de tus variables y métodos deben ser claras, legibles y entendibles.
¿A qué nos referimos con el código anterior? ¿Estamos hablando sobre obtener la información de una categoría, de un catálogo o de un gato (cat, en inglés)?
Lo anterior produce confusión y frustración. ¿Qué estás pidiendo en realidad?
Ahora si que, si tu variable contiene autos, tu variable debe llamarse $cars. Si tu variable contiene tipos de coches, entonces debes llamar a tu variable: $cars_types.
¿Entiendes mi punto?
Pero, tampoco te excedas en nombrar las cosas; es decir, trata de usar palabras cortas, siempre que puedas. Ejemplo:
Hemos usado una variable con una buena cantidad de caracteres; para ser sinceros, se hace un poco difícil de leer. La solución es usar alguna palabra corta:
Siempre trata de eliminar las palabras que agreguen complejidad a tu variable o función.
El nombramiento de las funciones y la documentación
La documentación es odiada por todos, yo la odio, pero es buena práctica escribirla, obviamente, clara y simple de entender, como lo hemos visto anteriormente.
¿Por qué? Tú puedes escribir tu código bien escrito, siguiendo las recomendaciones anteriores, pero, ¿qué pasa si quieres leer el código un año después que lo escribiste?
¡Así es! Probablemente no comprendas de qué se trate el código que escribiste, sin embargo, hay algunos casos en los que la documentación no es tan necesaria.
Una documentación puede ser opcional siempre y cuando tu código explique por si solo lo que está haciendo; por ejemplo, y es aquí donde aplicamos el buen nombramiento de las funciones:
Tenemos la función is_plugin_active() de WordPress, la cual sí tiene su propia documentación:
Pero podría ser opcional, ya que el mismo nombre de la función explica lo que está haciendo.
Sin embargo, está la función get_plugin_data(), cuya documentación abarca muchas líneas de código:
¿Notas la gran diferencia? Mientras más hagas entendibles tus códigos, menos documentación tendrás que escribir.
La documentación te ayuda a ti y a los demás programadores a entender el código que se ha escrito.
Conclusión
La buena práctica de nombrar bien las cosas es algo muy importante que debes tomar en cuenta, te ayuda a ti mismo y ayuda a demás programadores a ser mejores programadores.
Conocemos las condiciones en PHP, pero ¿qué tan eficientes son las que tu escribes? Las condiciones pueden afectar la legibilidad de tu código e incluso afectar el rendimiento de tu aplicación.
Los problemas en las condiciones
He visto a desarrolladores nuevos en grupos de Facebook publicar su código, ¿y saben qué es lo que he notado? Problemas en sus condiciones:
No son para nada legibles ni eficientes, por lo tanto, son complejas.
Ejecutan condiciones de más, provocando el famoso callback hell.
No utilizan las condiciones Yoda (Esto puede ser opcional en cada desarrollador, pero yo lo recomiendo como buena práctica).
Yo sufrí lo mismo; y es que cuando estás empezando a desarrollar en PHP, como que te cuesta encontrar una guía de buenas prácticas al momento de estar desarrollando.
Tu código debe ser legible, no lo hagas más complejo
Hay una verdad en los programadores:
Los programadores pasamos la mayor parte de nuestro tiempo leyendo código que escribiéndolo.
Por lo tanto, todo el código que nosotros escribamos, deberá ser legible para que tanto nosotros como otros programadores lo lean rápido y por ende, el código sea fácil de entender.
¿No queremos gastar nuestro tiempo tratando de adivinar lo que hace el código o si?
Lo siguiente pasa muy seguido en los desarrolladores nuevos:
¿Si notas cómo el código de arriba se hace un poco difícil de leer? Entre más tedioso sea de leer, más complejo se volverá tu código.
El código anterior es un ejemplo de condiciones anidadas. Ahora, ¿Qué ocurre cuando empiezas a anidar condición tras condición, función tras función?
Ocurre el famoso callback hell; la siguiente imagen no contiene código PHP, pero es un ejemplo muy claro de un callback hell, condiciones tras condiciones (abre la imagen en una pestaña para verla mejor, si es que te atreves):
¿Pudiste descifrar lo que hace el código? ¡Yo ni me tomé el tiempo de leerlo! Tan sólo mira esa complejidad. Eso es lo que tratamos de evitar.
La solución de nuestro código anterior sería usar los operadores lógicos, en este caso, el operador AND:
¿Notas la diferencia? Es más legible y menos complejo. Los operadores lógicos están aquí para ayudarnos, así que pon atención a tus clases de Matemáticas Discretas (bueno, al menos yo lo vi en esa materia).
Usa cláusulas de guardia
Éste método funciona como un guardia que protege tu código, para poder llegar a la siguiente sección del código debes pasar ese guardia, y así sucesivamente.
Gráficamente trabaja así:
¿Pero realmente de qué sirve? Nos aporta mayor legibilidad a nuestro código, nos ayuda a no ejecutar código de más y evita el callback hell.
El siguiente ejemplo no tiene cláusulas de guardia:
La función anterior nos dice que si el usuario está registrado, nos retorne los datos del usuario que está tratando de iniciar sesión, en caso contrario, mandemos un array vacío.
Ahora, mira la misma función pero usando las cláusulas de guardia:
¿Ves como hemos negado la función in_array()? Le estamos diciendo que si el usuario no existe, retorna un array vacío, en cambio, si existe, continúa con el código y obtiene los datos del usuario.
¡Así es como funcionan las cláusulas de guardia! Tienes que pasar cada guardia para proseguir ejecutando el código.
Otro ejemplo, pero ahora con condiciones anidadas:
La función anterior valida si el usuario actual que está tratando de iniciar sesión es un administrador o no. Pero, ¿si sientes que pierdes un poco de tiempo tratando de leer el código?
Bien, entonces, la función anterior sería de la siguiente forma usando cláusulas de guardia:
Copy
<?phpfunctionis_current_user_admin( $username ) { $usernames_list =array('roelmagdaleno','rokumetal','elbuenprogramador117', );if( !in_array( $username, $usernames_list ) ) {return'The user does not exists.'; } $user_data =get_user_data( $username );if( 'administrator'!== $user_data['role'] ) {returnfalse; }returntrue;}
¡Estupendo! Eliminamos la condición anidada y ahora es más fácil de leer el código, y un extra fue que evitamos un posible callback hell.
¿Tienes funciones que contengan condiciones anidadas? Trata de convertirlas usando cláusulas de guardia y pega tus resultados en los comentarios.
Evita usar “else” en tus condiciones
¿Enserio, no usar el else? Sí, hablo enserio.
¿No te ha pasado que cuando usas la palabra reservada else, se te dificulta leer más el código? Exacto.
Esta declaración lo que hace es agregarle más complejidad a nuestro código y por ende, más difícil de leer. Por ejemplo, sé que puedes leer el siguiente código, pero ¿cuánto te tardas en entender lo que realmente hace?:
Bueno, el código representa un inicio de sesión, pero volvemos a lo mismo: legibilidad y complejidad. Y todos hemos escrito código parecido al anterior, no me dejarán mentir.
¿Cómo podemos evitar el else? Aquí tenemos dos soluciones:
Usar funciones para validar los datos y cláusulas de guardia; por lo tanto, el código anterior quedaría de la siguiente manera:
Copy
<?php$username = $_POST['username'];$password = $_POST['password'];if ( empty( $username ) ||empty( $password ) ) {return'user-login.php';}if( !validate_password_and_user_data( $username, $password, $verification_code ) ) {return'Something is wrong with your data.';}return'All good! Go to dashboard.';functionvalidate_password_and_user_data( $username, $password, $verification_code ) {if( 'roelmagdaleno'!== $verification_code ) {returnfalse; } $sql ='My SQL query to get username data.';if( $password !== $sql['password'] ) {returnfalse; }returntrue;}
¿Es más código? Sí, pero ésta solución hace que nuestros ojos no sangren al momento de ver el código, y no, no hemos usado ni un else.
El operador ternario
Vamos a usar un código directo, ¿has escrito un código como el siguiente?
Copy
<?php$new_color ='';if( isset( $_POST['color'] ) ) { $new_color = $_POST['color'];} else { $new_color ='red';}echo'The current color is '. $new_color;
Lo que estamos haciendo en el código anterior es que si existe el valor de un color que es traído desde un formulario, lo asigne a la variable $new_color, pero, sino existe, asigna un color por default.
El operador ternario puede reducir este tipo de condiciones con la siguiente sintaxis:
Siguiendo la sintaxis anterior, nuestro código ahora sería:
Copy
<?php$new_color =isset( $_POST['color'] ) ? $_POST['color'] :'red';echo'The current color is '. $new_color;
¡Wow! Nos ahorramos 5 líneas de código.
Una buena práctica que siempre hago es hacer primero la condición sin el operador ternario, y después, ya que he analizado bien mi condición, aplico el operador ternario.
Si usas otro lenguaje de programación, busca en este enlace si es compatible, o puedes probar directo en tu código.
Operador de fusión de null
Y hay una característica mucho mejor, pero solo es a partir de PHP 7, y se llama: operador de fusión de null. Su sintaxis es:
Y nos sirve para verificar si una variable existe, y si existe y no es null, asigna ese valor a la variable, en caso contrario, asignará el valor por default. Por ejemplo:
Copy
<?php$username = $_GET['username'] ??'John Doe';
Si $_GET['username'] existe y no es null, entonces la variable $username será igual a $_GET['username'], en caso contrario, será igual a John Doe.
Realmente, este operador hace una operación ternaria por detrás. El código anterior equivale a esta operación ternaria:
Recuerda, sólo funciona a partir de PHP 7 para arriba.
Condiciones Yoda
No explicaré aquí lo que es una condición Yoda, ya que he escrito un post específico para ese tema, y lo puedes leer en éste enlace.
Aplica los conocimientos aprendidos
Me da mucho gusto que hayas llegado hasta aquí, y espero que hayas aprendido algo, pero si te ha quedado alguna duda, tienes algún comentario ó sientes que me faltó una buena práctica, me gustaría que la compartieras en la caja de comentarios.
También te invito a compartir esta guía de buenas prácticas para que más desarrolladores nuevos aprendan a desarrollar de manera legible y menos compleja.