Revista Economía

Etiquetas de tarea

Publicado el 26 mayo 2015 por Elvenbyte @elvenbyte

Ya sé que siempre hablo de temas muy técnicos, y muy específicos en ocasiones, o hago compendios larguísimos que no sé cuándo acabaré (como mi serie sobre las cachés). Pero tengo una razón importante, o que a mi me lo parece, para elegir esos temas.

Normalmente suele ser porque me han afectado de forma especial en mi trabajo, y no he encontrado información suficiente o interesante en Internet. Especialmente en castellano. Es es mi forma de aportar conocimiento a la Red.

Pero muy por encima de todas, como razón especial, porque me gusta escribir, y cómo no hacerlo precisamente sobre un campo que domino, como es la programación. Y dejo ya los sentimentalismos para pasar al tema en sí: las etiquetas de tarea.

Llevo varios años trabajando sobre código que han tocado cientos de manos antes que yo, lo cual acaba convirtiendo dicho código  en un infierno de sinsentidos. Variables y estructuras que se usan ensuciando la memoria, bloques de código funcional que de una forma casi paranormal no hacen otra cosa que llevarte a callejones sin salida, bloques de código comentado y comentarios en sí que no explican nada…

Y lo más frustrante de todo: etiquetas de tarea cuya función puede ser cualquier cosa (desde simples recordatorios, a complicadas formas de querer hacer más importante un comentario), menos para lo que están pensadas. Como mucho puedo entender aquellas en las que el programador en un principio quería que sirviera para algo a posteriori, pero que se quedó perdida en el olvido. Aunque ni siquiera estas puedo tolerarlas.

Pequeña reflexión sobre los comentarios

Cuando comenzó el mundo de la programación, digamos que por aquellos tiempos de las tarjetas perforadas, si no antes, el código fuente, que no se conocía como tal, eran relativamente pequeños fragmentos de cálculos que en su mayor complejidad se unían entre ellos para formar un programa, que no era sino el resultado de aquellos cálculos como objetivo final.

Cuando aparecen los monitores y los lenguajes más parecidos al humano (concretamente al inglés, salvo alguna que otra excepción), el código se vuelve más complicado, más extenso, y necesita ser explicado. Allí aparece la posibilidad de incorporar comentarios al código. Más o menos y a muy grandes rasgos.

Probablemente, la aparición de los comentarios fue la causante, en parte, de que se empezase a escribir mal código. Total, los comentarios ya explicaban lo que este hacía.

Con el paso del tiempo nos hemos dado cuenta de que podríamos obviar muchos de esos comentarios, utilizando técnicas como variables autonombrables (“temporizador”, en lugar de “t”, y cosas así), o usando normativas como la escritura del código “java like”, o siguiendo unas pautas de sentido común en muchas de los casos.

Hace poco comentaba con un compañero programador, que los programadores de hoy no son programadores comprometidos con el código que escriben y desgraciadamente, según mi experiencia, así es.

Pero, ¿en qué momento es bueno usar comentarios?

Hasta ahora, en ningún momento he dicho que el uso de los comentarios sea malo. De hecho pienso que los comentarios son un recurso necesario, por no decir imprescindible, en programación. Siempre y cuando estos se utilicen de forma correcta.

Hoy en día, y bajo mi punto de vista, la forma correcta sería bajo las siguientes premisas:

  • Para explicar un bloque de código especialmente complicado de leer.
  • Para documentar métodos y funciones, al estilo JavaDoc.
  • Y para su uso con las etiquetas de tarea.

Qué son las etiquetas de tarea, respecto al comentario tradicional

Podemos considerar la etiqueta de tarea como una evolución práctica y lógica del comentario tradicional. Una etiqueta de tarea es un comentario recurrente. Lo explico.

Mientras que el comentario tradicional tiene un uso irreflexivo, es decir que se escribe sin el ánimo de volver a él, al menos de forma reflexiva, la etiqueta de tarea se escribe con la intención de volver a ella antes de dar por finalizada la escritura del código.

O esa debería ser su mecánica, si nos afanáramos en darle un buen uso, que no es más que aquel con el que se idearon.

Su gestión a través del IDE

Algo que confirma todo esto es precisamente que los IDEs más avanzados tienen gestores internos a propósito de las etiquetas de tarea. No me refiero a los editores más básicos, como Notepad++ o Sublime Text, sino a IDEs como Eclipse o Netbeans.

No voy a entrar en si por ello son mejores, unos que otros, ya que eso puede dar para no uno, sino varios posts. Pero sí quiero hacer hincapié en el hecho de que se integren esos gestores de etiquetas, porque eso te hace ver, en su uso, quién es más responsable con la documentación necesaria del código, y quién no.

Y no es sea necesario un IDE para el uso de las etiquetas de tarea. Con un buen sistema o metodología de trabajo, y la propia herramienta de búsqueda de cualquier editor, nos basta para un buen uso de las etiquetas de tarea.

Es una simple cuestión de sentido común.

Flexibilidad

Las etiquetas de tarea más utilizadas comúnmente son las siguientes:

  • TODO: utilizada principalmente para dejar constancia de que falta algo por hacer en el código bajo la etiqueta.
  • FIXME: cuando se ha detectado un error en el código, pero se deja su resolución para un momento posterior.
  • NOTE: esta es muy poco utilizada, y sirve para que se tenga en cuenta por el motivo que se describe en el texto que la acompaña, antes de dar por finalizado el código.

Pero también de sentido común es el hecho de que, siendo al fin y al cabo una etiqueta de tarea nada más que un comentario, como he dicho antes, con un buen sistema o metodología, podemos utilizar y/o incorporar nuestras propias etiquetas de tarea.

Por ejemplo, yo suelo utilizar test unitarios en mi programación, bien con jUnit si estoy en java, o phpUnit si en PHP. Pero no siempre tengo la oportunidad de trabajar con pruebas unitarias, así que hago estas dentro del mismo código, viéndome en la obligación de incorporar “hard code” que debo eliminar antes de entregar el código final. Para indicar esto utilizo una etiqueta TEST.

El uso de etiquetas de tarea implica añadir una tarea final en nuestra rutina o disciplina de trabajo, que es revisarlas antes de entregar. Sin esto no sirve de nada que las incorporemos a nuestro trabajo diario.

Etiqueta de tarea o tarea

Las etiquetas de tarea no son tareas. Estoy hay que tenerlo muy claro. Las tareas son el trabajo que hay que hacer en sí, lo que vamos a entregar.

Las etiquetas de tarea son como un post-it que colocamos en una documentación con las cosas que hay que hacer, o tener en cuenta, respecto a esa documentación.

Yo recomiendo el buen uso de las etiquetas de tarea. A mi me vienen muy bien.

Share

Volver a la Portada de Logo Paperblog