Как управлять материалом программирования @todo? [закрытый]

В основном я использую три системы для различных видов TODO объектов:

• Блокнот для краткосрочных объектов (таких как сегодня или на этой неделе)
• Комментарии TODO плюс поддержка IDE (например Eclipse Tasks view) для небольших, более долгосрочных объектов
• Трекер проблем, такой как Trac plus IDE (например, Mylyn) для более сложных, более долгосрочных объектов

Для vim существует также скрипт Tasklist, вдохновленный списком задач Eclipse, который соскребает TODO, FIXME и т.д. в ваших текстовых файлах и отображает их как список в дополнительном буфере (см. screenshot).

Я бы не стал использовать @todo javadoc аннотацию, потому что IMO она не должна попадать в документацию.
Документация должна быть публичной , не идеальной для TODO.
ТДО также должны приближаться к коду, к которому они относятся, что является преимуществом использования комментариев.

Для небольших задач, таких как моя обычная //todo, я использую локальные задачи в Eclipse Mylyn, для больших задач (даже если я думаю, что их можно назвать функциями или ошибками) я использую Trac; если вы обнаружите, что ваш код полон TODO, пришло время получить систему управления билетами.

Может быть, вы можете использовать find и grep для поиска этих ключевых слов в ваших проектах

проблема с todo-флагами такая же, как и с предупреждениями (например, компилятор java, checkstyle). если они появляются часто, то вы их игнорируете. в вашем случае я бы отслеживал их через отчет системы сборки (например, maven или ant). в конце каждой итерации следует делать правило, что количество todo-флагов уменьшается.

меньше todo-флагов означает:

• решение их
• удаление, потому что они устарели (что часто случается, если вы никогда не приводите в порядок код)

обычно не используют todo-флаги для всех задач. для меня это просто маленькие напоминания или рефакторинги-todos. более крупные задачи всегда должны отслеживаться билетной системой (например, trac или jira).

Я использую FIX! вместо TODO. Количество восклицательных знаков указывает на приоритет. IntelliJ позволяет настроить для них пользовательские фильтры, чтобы я мог посмотреть на комментарии уровня 3 "FIX!!!" и разобраться с ними.

Может быть, Доксиген поможет?

Доксиген распознает эти ///@TODO:s и создает с их помощью список.

А так как Doxygen может использовать комментарии в стиле Javadoc, я думаю, что попробовать его довольно просто.

Если вы используете Maven, вы можете использовать taglist-maven-плагин для сканирования исходных файлов на наличие тегов (любой тег, который вы хотите, это настраивается) и генерирует отчет об их возникновении.

Плагин Taglist Maven Plugin формирует отчёт по различным меткам найденный в коде, как @todo или //TODO теги

но отслеживание тегов легкая часть, исправляя их немного труднее и занимает больше времени :)

Если ваши операторы TODO так сильно вас беспокоят и вызывают такое сильное недовольство при их просмотре, я бы написал небольшой скрипт в процессе сборки, который обнаруживает и подводит компиляцию. Пусть он провалится так же, как и на предупреждающих выражениях.

Операторы TODO могут остаться в коде навсегда, что плохо, потому что // Подробный ответ TODO

TODO подходит для небольшой команды, но если вы ведете проект с открытым исходным кодом или каким-либо образом расширяете доступ для разработчиков, потребуются другие варианты, такие как TO_DO, fixme, XXX, ПРИМЕЧАНИЕ, HACK, bug, your_defect_tool_here и т. Д. сканирование в любом случае. Немного тяжеловесно, но мой протокол TODO будет выглядеть так:

TODO: yy-mm-dd: author: your_comment

Наконец, сделайте комментарий, который вы оставляете, стратегический, а не проектное заявление или мнение.