Como desarrolladores no solo es importante saber transformar nuestras instrucciones en un lenguaje de programación para resolver problemas con el poder del ordenador, también es importante documentar y saber cómo comunicar tanto a otros desarrolladores como a perfiles menos técnicos nuestras creaciones, por esta razón, quiero compartir una práctica imprescindible para cualquier desarrollador de software, sin importar el lenguaje.

El código semántico o “semantic code” en inglés, significa escribir código que describa el contenido del mismo o su funcionalidad, al contrario de enfocar tu código en cómo se visualiza. En el caso de JavaScript esto podría ser un debate en utilizar el clásico “if else statement” o el “ternary operator”.

Por ejemplo piensa en las etiquetas HTML, las cuales fueron creadas con un fin semántico (descriptivo), es posible utilizar un div para escribir y visualizar cualquier tipo de estructura, sin embargo utilizar las etiquetas correspondientes para describir el contenido del mismo hace que el contenido sea más fácil de entender, incluso mejora los resultados de búsqueda del SEO “Search Engine Optimization”, porque los robots de los diferentes gigantes tecnológicos, pueden diferenciar y ponderar (ordenar por mayor importancia) el contenido de tu sitio web.

Como buenos desarrolladores es importante pensar a largo plazo, sabemos que gran parte de nuestra labor no solo es crear sino mantener, actualizar y mejorar, al escribir código de forma semántica, ayudamos a nuevos colegas que forman parte del equipo, a entender mejor las aplicaciones desarrolladas, facilitando su lectura con variables bien definidas y con estructuras coherentes.

Tanto escribir código de manera semántica, como escribir código con una sintaxis moderna, es un equilibrio que cada desarrollador o equipo de desarrollo deberá definir con base a su experiencia y preferencias personales, lo más importante, es tener claro que el escribir código de una manera semántica, significa que conforme lees cada línea del editor de código, entiendas bien qué es lo que está sucediendo, como si leyeras un correo electrónico importante y éste te quedo claro al leerlo una sola vez, sin tanta concentración y sin tener que ir a la historia de la conversación o buscar otros recursos para dar contexto a dicha comunicación.

Ejemplo

Tomando uno de los posibles ejemplos de pruebas con algoritmos, que solicitan en las entrevistas de trabajo para desarrolladores, el ejemplo es el siguiente:

Completa la siguiente función para que al ingresar como entrada un arreglo con diferentes alturas de las personas que se encuentran esperando en una fila dentro de un parque, éstas sean ordenadas de forma ascendente según su estatura, además en el arreglo están contemplados tres valores con -1 que representan los árboles en el lugar de la fila de espera, los cuales no se pueden mover.

Solución sin código semántico 😒

Solución con código semántico 😀

Nombrar las variables de una manera descriptiva ayuda a entender mejor qué está sucediendo en cada paso de la solución, puede que como desarrollador con más experiencia no te importe este tema, porque ya pasaste años rompiendote la cabeza con variables feas y mal definidas, eso no es pretexto, es importante seguir mejorando y ayudar a las nuevas generaciones.

Es muy debatible si es mejor práctica utilizar sintaxis moderna y abstracta o clásica pero descriptiva. Respecto a este punto considero que en general todas las mejoras que hacen a los lenguajes tienen su fundamento, a pesar de que en un inicio experimentemos resistencia al cambio, con el paso del tiempo se vuelve más familiar y hace más sentido, también es cansado ver siempre la misma sintaxis, por ejemplo ver un operador ternario ahora me gusta más que un “if statement clásico”, si agregas una visualización con saltos de línea y espaciado, se notará más elegante como es el caso de la línea 6 a 10 del ejemplo con código semántico.

En general a mi me gusta tener una sintaxis, sencilla, limpia, con algunos saltos de línea e incluso espacio extra en los paréntesis, al inicio pensaba que era un pérdida de tiempo, pero hace mas agradable a la vista del lector contar con más espacio, puedes concentrar tu vista en los detalles importantes, por eso cuando es posible y hace sentido, me gusta eliminar las llaves y la palabra “return” en los “callbacks”, además se ve mas elegante y si estás haciendo entrevistas de trabajo, en las pruebas técnicas les gusta mucho a los entrevistados que utilices la sintaxis más moderna.

punto y coma al final ;

Gracias a que desde el ES6 son opcionales, me gusta prescindir de ellos (salvo en casos obligatorios como en el for loop clásico) porque hace que tu código se vea más limpio y entendible, si tienes un buen espaciado y saltos de línea; vuelvo a repetir, esto es preferencia personal, sino te gusta utilizarlos pero en tu equipo de desarrollo los piden, siempre puedes contar con “Prettier” para que al guardar agregue todo lo necesario respecto al formato.