¿Los comentarios de TODO tienen sentido? [cerrado]

Tiendo a usar // todo comentarios para que sucedan cosas que tienen , pero no puedo hacer de inmediato.

También me cercioro de que los busco, los busco (Visual Studio tiene una buena función en la que incluirá esos comentarios) y me aseguro de que todo esté hecho.

Pero, como usted dice, no todos son diligentes con ellos y, como muchos comentarios, tienden a pudrirse con el tiempo.

Yo diría que esto es más una preferencia personal, siempre que documente lo que se debe hacer y lo busque, no importa si está en // todo , notas postit o una pizarra (donde también pueden terminar sin ser accionados).

Los IDE modernos reconocen el TODO de los comentarios y, como tales, son visibles en su propio panel / ventana / pestaña, por lo que en teoría no se pierden (estoy pensando en Eclipse y Visual Studio, ambos lo sé lo suficiente como para recordar que Reconócelo).

Incluso puede configurar palabras de comentario adicionales como FIXME , BEWARE o cualquier otra cosa que desee personalizar. Sin embargo, otros desarrolladores en su proyecto tendrán que personalizar su IDE de la misma manera.

Ahora, escribí "teóricamente" porque, aunque no está perdido, TODO se relaciona más a menudo con algo que no es necesario para que la aplicación funcione correctamente "en este momento". Y "en este momento" puede extenderse por 5 minutos a 5 años, dependiendo del tipo / tamaño del proyecto :-)

Finalmente, en mi opinión, todavía tiene más sentido tenerlos en el código, en el lugar correcto, respondiendo precisamente a la pregunta "¿dónde debería hacer el cambio" que en otro lugar fuera del código?

Editar: como está escrito en el artículo de Wikipedia , incluyendo la fecha y el propietario del TODO se considera una buena práctica.

Puede tener algún sentido, al menos los uso a veces. El punto clave es usar etiquetas consistentes como TODO o FIXME para que se puedan encontrar fácilmente con una simple búsqueda de texto.

Por ejemplo, las soluciones "rápidas y sucias" son convenientes de etiquetar, algo como:

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

Si el código hace lo que se supone que debe hacer, y nadie se queja, el comentario no hace daño. Si alguna vez hay tiempo para embellecer el código, es fácil comenzar con la búsqueda de FIXME labels.

En mi industria, se recomienda a los desarrolladores que realicen entradas JIRA (o etc) en lugar de comentarios pendientes porque no todos tienen la oportunidad de ver las entradas // todo . Pero a veces, en grandes proyectos, un atributo personalizado se define de la siguiente manera:

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

Y entonces un método puede ser decorado de esta manera ...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

Y los superiores pueden venir y cosecharlos automáticamente. Puede ser una exageración para el simple recordatorio de // todo , pero es efectivo. También requiere una plataforma .NET.

En mi experiencia depende. El factor principal es si el equipo es lo suficientemente disciplinado como para dar seguimiento a estos "pequeños" comentarios. Si lo hacen, entonces sí tienen sentido. Si no es así, estos comentarios son solo una pérdida de tiempo y es posible que desee ver otras opciones, por ejemplo. tarjetas de historia.

Personalmente uso TODO comentarios de vez en cuando, pero por lo general son de corta duración y por lo general solo tengo un número muy pequeño de ellos como uno, dos o tres. Los uso más como un marcador en la base de código que cualquier otra cosa. Si espero demasiado para cuidarlos, me olvido de lo que pensé que necesitaba "hacer".

Mi preferencia siempre sería no usarlos y, en cambio, usar tarjetas de historia o trabajos pendientes o similares. Utilice un mecanismo para una tarea.

TODO es solo un subformulario de comentario. Los comentarios son de gran utilidad si el escritor tiene alguna habilidad para saber qué transmitir y cómo transmitirlo. El sentido del humor también se puede aplicar aquí en pequeñas dosis para deleitar a los mantenedores años más tarde.

El año pasado recibí una llamada de que parte de mi código estaba siendo retirado. Me impresionó bastante que hubiera estado en producción y sobreviviera al mantenimiento durante 16 años. Así que ten cuidado, tu código podría durar MUCHO tiempo. Los comentarios sobre la intención, las necesidades futuras, etc. pueden ayudar mucho a ayudar a alguien que se encuentra a partir de ahora y que está viendo su código por primera vez.

Solía escribirlos en el pasado, pero me he dado cuenta de que normalmente no los seguís.

Por lo tanto, ahora solo los uso para marcar las cosas en las que quiero trabajar justo después de terminar con lo que estoy ocupado. Por ejemplo, implemento una nueva función y me doy cuenta de que una función que uso tiene un pequeño error; Hago un FIXME para solucionar este problema para evitar que se desvíe de mi tarea actual.

Para ayudarme, nuestras compilaciones de CI están configuradas para fallar si hay FIXMEs en el código :-).

Si observa problemas potenciales que no se pueden resolver de inmediato, abra un ticket / error / problema para ellos. De esa manera, se pueden priorizar como todos los errores. Creo que esto es mucho mejor que tener algunos problemas en la base de datos de errores y algunos en el código como TODOs.

Opcionalmente, puedes poner un TODO con el ID de error :-).

Creo que TODO comentarios, hasta cierto punto, tiene sentido. En particular, si está trabajando de manera iterativa (como es común en las tiendas ágiles y TDD), habrá cosas que reconozca que son que se necesitarán en poco tiempo, pero que no desea desviarse. Implementar en ese momento y allí.

Lo que se pone feo es cuando dichos comentarios permanecen en el código base. Mientras está trabajando activamente en una función, está bien dejarlos dentro, pero tan pronto como se acerque a completar la función, debe concentrarse en deshacerse de ellos. Si no quiere pasar por el trabajo de realmente reemplazarlos con un código de trabajo adecuado, entonces al menos elimine la funcionalidad relevante. Tomar prestado el ejemplo de @ JoonasPulakka, donde el código dice inicialmente

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

puedes cambiar eso por algo como

ConnManager.getConnection(GetDatabaseName());

con, por el momento, GetDatabaseName () es un código auxiliar que simplemente devuelve la misma cadena con la que comenzó. De esa manera, hay un punto claro de expansión futura, y sabe que cualquier cambio realizado allí se reflejará en cualquier lugar donde se necesite el nombre de la base de datos. Si el nombre de la base de datos es incluso moderadamente genérico, esto puede ser una mejora masiva en la capacidad de mantenimiento.

Personalmente, uso una palabra clave propia en lugar de estrictamente TODO , aunque la intención es la misma: para marcar las cosas que sé que necesitarán volver a visitar. Además, antes de verificar mi código, hago una búsqueda global de código fuente para esa palabra clave, que se elige de tal manera que normalmente no debería aparecer en ninguna parte del código. Si se encuentra, sé que olvidé algo y puedo seguir adelante y arreglarlo.

En cuanto a incluir el nombre / la firma del programador con el comentario, creo que eso es excesivo si tiene un sistema de control de versión de código fuente ( do , ¿verdad?). En ese caso, su función de culpar te dirá quién agregó el comentario, o más exactamente quién verificó por última vez un cambio que tocó el comentario. Por ejemplo, en Visual Studio, esto se logra fácilmente mediante el uso de la función "Anotar" que se encuentra entre las funciones de control de origen.

Por lo general, no hago // TODO comentarios, pero los guardo en un archivo separado. Todavía no puedo encontrar / escribir software en línea para administrarlos fácilmente, por lo que los archivos TODO siguen siendo los más útiles para mí porque, cuando abro el proyecto, incluso después de poco tiempo, me olvido de lo que debo hacer ahora y luego miro el archivo TODO y hago el trabajo. . Tengo "filename.cpp 354: Recodificar este bla bla bla" y es mucho más útil que buscar // TODO comentario en el archivo. Hice // TODO earler cuando era perezoso, pero simplemente quité esos // TODO-s del archivo fuente y no los arreglo cuando el proyecto funciona bien. Recomiendo encarecidamente mover todos // TODOs de la fuente a un lugar separado y mantenerlos junto con otros todos para que pueda priorizar las tareas con facilidad. La prioridad es realmente difícil DE HACERLO cuando tienes todas tus TODO en varios archivos y proyectos.

Creo que hay gran, pero no solo. Por ejemplo:

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

Este enfoque funciona bastante bien con moderación. Aunque tendría que decir que convertirlo en un hábito de lanzar excepciones para recordarle que complete un código no es realmente el enfoque más profesional. Pero me ha salvado en algunos casos en los que crees que completaste algo e incluso escribiste que completaste cuando no lo has hecho.

Si escribes TODO o FIXME con la idea de que alguien más lo arreglará cuando llegue a ese código en un futuro indeterminado, entonces diría que no te preocupes. Desecharán el código y desordenarán la parte de informe de su IDE que recopila esta información.

Para ser útiles, deben proporcionar un medio para marcar su código en un futuro (muy) cercano para que pueda volver a su estado mental más rápido. En otras palabras, los coloca en su código solo para eliminarlos lo antes posible.

De hecho, cualquier cosa de mayor duración debe colocarse en la base de errores donde pertenece.

Hay suficiente ruido en nuestras vidas, no creemos una nueva fanfarria de cosas que piden atención mientras se requiere en otros lugares.

Mi 2 centavo

La gran ventaja de los comentarios de tareas pendientes sobre cualquiera de los otros millones de maneras en que se puede crear una lista de tareas es que los comentarios de tareas viajan con el código para que no puedan separarse.

Probablemente, el lugar más apropiado para este tipo de cosas es el rastreador de problemas en lugar del código.

Recomiendo encarecidamente que cada TODO o FIXME se ingrese en un registro formal. Si no lo están, se pueden buscar fácilmente, y debería ser una fase en cada iteración para verificar TODO y FIXME pendientes. Luego se pueden catalogar y configurar para una solución inmediata, o el equipo puede planificar para corregirlos en el momento adecuado.

Finalmente, una vez resueltos, deben eliminarse; si no se eliminan de manera sistemática después de ser resueltos, perderán su efectividad.

Conclusión: son mejores que no registrar problemas en absoluto, pero realmente hay que mantenerlos.

IntelliJ realmente le avisará si intenta confirmar un código que tiene TODO nuevo. Por lo tanto, siempre se puede interpretar un TODO como "esto realmente debería suceder cuando me comprometo".

Cuando consideras el "TODO" como una etiqueta semántica para tu comentario, creo que tienen sentido.

En los estándares de codificación de mi compañía, especificamos que las iniciales del desarrollador responsable deben incluirse con TODO ( es decir , escribiría "SAA TODO:"). Creo que esto es útil, al menos como una convención, porque de lo contrario, existe la tentación de dejar un código de calidad inferior con la nota TODO para que algún desarrollador futuro se ocupe.

Como ayuda, muchos IDE pueden configurarse para agregar estos comentarios a una lista de tareas, lo que permite que se traten de manera similar para generar faltas y no se olviden indefinidamente.     

Un método más desagradable y efectivo es probablemente convertir sus comentarios de tareas pendientes en mensajes del compilador, de esa manera usted y todos los demás lo verán cuando se compile el programa.

en Delphi:

{$message 'todo: free this thing when you know its not going to blow up'}

En mi experiencia, TODO debería usarse para indicar que un fragmento de código no se puede utilizar y le dice al lector qué se necesita para que sea utilizable (localmente o en otro lugar).

TODO no deben usarse para indicar que algún fragmento de código sería mejor si se modificara de alguna manera. Los ejemplos incluyen código sucio que sería más mantenible si se reescribiera o una característica adicional que nadie necesita todavía. Esas anotaciones tienden a acumularse y hacen que un grep TODO devuelva resultados inútiles.