Durante muchos años mi código estaba lleno de este tipo de comentarios:¿Cómo administrar @todo cosas de programación?
//TODO : Add ...
...
/*
*TODO : Fix ...
*
*/
ahora pienso para crear mi propia anotación @todo javadoc ... pero antes de hacer eso me gustaría saber si es lo que ustedes tienen mejor manera para administrar su todo cosas de programación?
Su IDE (Eclipse, NetBeans, ..) tiene un plugin de tareas, que detecta todos los TODO sy los muestra en una lista. En Eclipse es Window > Show View > Other > Tasks
No es necesario que escriba su propia anotación.
En NetBeans son los elementos de acción –
Para tareas pequeñas como mi habitual // todo uso tareas locales en Eclipse Mylyn, para tareas más grandes (incluso si creo que se las puede llamar características o errores) utilizo Trac; Si encuentra su código lleno de TODOs, es hora de obtener un sistema de administración de boletos.
Para vim también existe este script Tasklist, inspirado en la lista de tareas de Eclipse, que raspa para TODO, ARREGLAME, etc., en los archivos de texto y los muestra como una lista en una memoria intermedia adicional (ver screenshot).
No sabía que esto existía. ¡Gracias! –
básicamente utilizo tres sistemas para diferentes tipos de TODO artículos: Libreta
+1 para el rastreador de problemas (y el papel) –
Tal vez usted puede utilizar encontrar y grep para buscar aquellos clave palabras en sus proyectos
problema con todo banderas es el mismo que con las advertencias (p. compilador de java, checkstyle). si aparecen con frecuencia, los ignorarás. en su caso, los rastrearía a través de un informe de un sistema de compilación (por ejemplo, maven o hormiga). al final de cada iteración debe hacer una regla, que el número de indicadores de todo se reduce.
menos TODO-flags significa:
generalmente no utiliza TODO banderas para todas las tareas. para mí son solo pequeños recordatorios o refactorizaciones, todos. tareas más grandes siempre deben ser rastreados por un sistema de tickets (como trac o jira).
Utilizamos un complemento para Hudson que mostraba los TODO a lo largo del tiempo: es público y visible, lo que significa que hay más impulso para reducirlo con el tiempo. – SteveD
¿Quizás Doxygen puede ayudarlo?
Doxygen reconoce esos /// @ TODO: s y crea una lista con ellos.
Y dado que Doxygen puede usar comentarios de estilo Javadoc, creo que es algo fácil de probar.
Si sus declaraciones TODO le molestan tanto y le causan tanta angustia al verlas, escribiría un pequeño script en el proceso de compilación que detecta y falla la compilación.Ha fallado de la misma manera que falla en las declaraciones de advertencia.
Utilizo FIX! en lugar de TODO. La cantidad de signos de exclamación indica la prioridad. IntelliJ le permite configurar filtros personalizados para estos, para que pueda ver el nivel 3 "¡ARREGLAR!" comentarios y abordar esos.
No utilizaría una anotación javadoc @todo porque IMO no debería entrar en la documentación.
La documentación debe ser public, no es ideal para TODO.
TODOs también deben ir cerca del código con el que se relacionan, una ventaja del uso de comentarios.
Si está utilizando Maven, puede usar el taglist-maven-plugin para escanear los archivos fuente de las etiquetas (cualquier etiqueta que desee, esto es configurable) y genera a report en sus ocurrencias.
El taglist Maven Plugin genera un informe sobre diversas etiquetas encontrado en el código, como
@todoo//TODOetiquetas
Pero el seguimiento de las etiquetas es la parte fácil, la fijación de ellos es un poco más difícil y toma más tiempo :)
+1: Solo siembro un informe de muestra: ¡realmente interesante! –
declaraciones TODO conllevan el riesgo de quedar en el código para siempre, lo cual es malo porque // TODO elaborate answer
Es mejor que tener el problema/problema real dejado en el código para siempre –
@OliverWatkins Estoy de acuerdo. TODO tiene al menos dos ventajas: identifica algo como un problema pendiente, y es fácil de buscar. A pesar de esto, he visto docenas de comentarios TODO que nunca habían sido "resueltos" por sus autores. Para mí, esto es solo trabajo sin terminar. –
Normalmente escribo un número de ticket junto a TODO, de modo que cualquiera que se encuentre con el código, mientras hace otra tarea, verá qué deuda técnica está presente en este lugar. Hace que sea más fácil analizar cómo puede afectar la finalización de la tarea (por ejemplo, que tiene que terminar esta deuda técnica, o que su tarea puede ser rechazada tanto más difícil de lo estimado).Si no hay TODO en el código, es posible que no tenga conocimiento de la deuda técnica que ha completado mientras cumple con algún requisito comercial. – user3707125
TODO está bien en un equipo pequeño, pero si abre el proyecto de código fuente o amplía el acceso de desarrollador de cualquier forma, las otras variantes como TO_DO, fixme, XXX, NOTE, HACK, error, "your_defect_tool_here" y así sucesivamente necesitan escaneo para de todos modos. Un peso pesado poco, pero mi protocolo TODO se vería así:
TODO: aa-mm-dd: Autor: your_comment
Por último hacer el comentario que hace salir, no una declaración de diseño estratégico u opinión.
Esto puede ser independiente del idioma ... –
las anotaciones no son independientes del idioma ... – TofuBeer
@Martinho & TofuBeer: Es un comentario del código fuente ... en la mayoría de los casos es estricto para el idioma ... pero en proyectos "multinivel" una solución agnóstica como IDE puede ser muy buena ... –