Как вы помечаете код, чтобы потом вернуться и поработать над ним?

Отметьте их с помощью // TODO, // HACK или других маркеров комментариев, которые будут отображаться на панели задач в Visual Studio.

См. Использование списка задач.

Комментарий Todo.

// TODO: Имя человека - исправьте это.

Это в Java, затем вы можете просмотреть задачи в Eclipse, которые найдут все ссылки на этот тег и могут сгруппировать их по лицам, чтобы вы могли назначить TODO кому-то другому или посмотреть только на свои собственные.

Добавить тест в отключенном состоянии. Они отображаются во всех отчетах о сборке.

Если это не сработает, я сообщаю об ошибке.

В частности, я не видел, чтобы количество комментариев TODO хоть сколько-нибудь значимо уменьшалось. Если бы у меня не было времени сделать это, когда я писал комментарий, я не знаю, почему у меня было бы время позже.

gvim выделяет желтым цветом как «// XXX», так и «// TODO», что меня поразило, когда я впервые отметил код таким образом, чтобы напомнить себе, что нужно вернуться к нему.

Если мне нужно все бросить посреди смены, тогда

#error finish this

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

Комментарии «Сделать» хороши в теории, но не так хороши на практике, по крайней мере, по моему опыту. Если вы собираетесь отвлекаться на достаточно долгое время, чтобы они могли понадобиться, то о них, как правило, забывают.

Я предпочитаю общую стратегию Джона Т., но обычно я делаю это, просто временно нарушая код - я часто вставляю намеренно неопределенную ссылку на метод и позволяю компилятору напоминать мне о том, к чему мне нужно вернуться:

PutTheUpdateCodeHere();

Также комментарий Todo.

Мы также добавили специальное ключевое слово NOCHECKIN, мы добавили фиксацию в нашу систему управления версиями (очень легко сделать, по крайней мере, с cvs или svn), где он сканирует все файлы и отказывается проверять файл, если он находит текст НОЧЕКИН где угодно.

Это очень полезно, если вы просто хотите что-то протестировать и быть уверенным, что это случайно не будет проверено (прошло внимательным взглядом во время сравнения всего, что передано в систему управления версиями).

Я использую комбинацию //TODO://HACK: и throw new NotImplementedException(); в своих методах, чтобы обозначить незавершенную работу. Кроме того, я добавляю закладки в Visual Studio на незавершенные строки.

Мне очень понравился подход «Взломанные бомбы», продемонстрированный Ореном Эйни здесь.

try
{
   //do stuff
   return true;
}
catch // no idea how to prevent an exception here at the moment, this make it work for now...
{
  if (DateTime.Today > new DateTime(2007, 2, 7))
    throw new InvalidOperationException("fix me already!! no catching exceptions like this!");
  return false;
}

Я использую // TODO: или // HACK: как напоминание о том, что что-то не закончено, с примечанием, объясняющим, почему. Я часто (читаю «редко») возвращаюсь и заканчиваю эти дела из-за нехватки времени. Однако, когда я просматриваю код, у меня есть запись о том, что осталось незавершенным и, что более важно, ПОЧЕМУ.

Еще один комментарий, который я часто использую в конце дня или недели:

// НАЧАТЬ ЗДЕСЬ КРИС

^^^^^^^^^^^^^^^^^^^ Сообщает мне, где я остановился, чтобы я мог минимизировать время начальной загрузки в понедельник утром.

// TODO: <explanation>

если это то, что я еще не реализовал и не хочу забывать.

// FIXME: <explanation>

если это что-то, что, по моему мнению, не работает правильно, и я хочу вернуться позже или посмотреть на это другими глазами.

Никогда не задумывался о параметрах # error / # warning. Те тоже могут пригодиться.

//TODO: Finish this

Если вы используете VS, вы можете настроить свои собственные теги задач в разделе Инструменты> Параметры> Среда> Список задач.

Я использую // FIXME: xxx для неработающего кода и // CHGME: xxx для кода, который требует внимания, но работает (возможно, только в ограниченном контексте).

Это три разных способа, которые я считаю полезными, чтобы отметить то, что необходимо решить.

1. Поместите флажок комментария рядом с кодом, который необходимо просмотреть. Большинство компиляторов могут распознавать общие флаги и отображать их в организованном виде. Обычно в вашей среде IDE есть окно наблюдения, специально разработанное для этих флагов. Наиболее распространенный флаг комментария: // TODO Вот как вы его используете:

   // ЗАДАЧА: Исправьте это перед выпуском. Это вызывает нарушение прав доступа, поскольку использует память, которая еще не создана.

2. Один из способов отметить то, что необходимо решить перед выпуском, - это создать бесполезную переменную. Большинство компиляторов предупредит вас, если у вас есть переменная, которая не используется. Вот как вы можете использовать эту технику:

   int This_Is_An_Access_Violation = 0;

3. Закладки IDE. В большинстве продуктов есть возможность разместить закладку в коде для дальнейшего использования. Это хорошая идея, за исключением того, что ее видите только вы. Когда вы делитесь своим кодом, большинство IDE не будут делиться вашими закладками. Вы можете проверить файловую систему справки своей IDE, чтобы узнать, как использовать ее функции закладок.

Я также использую TODO: comments. Я понимаю критику в отношении того, что они редко исправляются и что лучше сообщать о них как об ошибках. Однако я думаю, что здесь упускается пара моментов:

• Я использую их чаще всего во время тяжелой разработки, когда я постоянно рефакторирую и переделываю что-то. Так что я все время на них смотрю. В подобных ситуациях большинство из них действительно решаются. Плюс к этому легко выполнить поиск TODO: чтобы убедиться, что я ничего не пропустил.

• Людям, читающим ваш код, может быть очень полезно знать места, которые, по вашему мнению, были плохо написаны или взломаны вместе. Если я читаю незнакомый код, я обычно ищу организационные шаблоны, соглашения об именах, последовательную логику и т. д. Если эту согласованность пришлось нарушить один или два раза для целесообразности, я бы предпочел увидеть примечание на этот счет. Таким образом, я не трачу время на поиски логики там, где ее нет.

Как и большинство программистов, я использую комментарии TODO. Кроме того, я использую интерфейс задач Eclipse Mylyn. Когда задача активна, Mylyn запоминает все открытые мной ресурсы. Так я могу отследить

1. где в файле я должен что-то сделать (и что),
2. в каких файлах я должен это делать, и
3. к какой задаче они относятся.

Помимо отключения комментария «TODO:», многие IDE также отключают комментарий «TASK:». Некоторые IDE даже позволяют настроить собственный специальный идентификатор.

Если это какой-то долгосрочный технический долг, вы можете прокомментировать так:

// TODO: This code loan causes an annual interest rate of 7.5% developer/hour. Upfront fee as stated by the current implementation. This contract is subject of prior authorization from the DCB (Developer's Code Bank), and tariff may change without warning.

... эээ. Я предполагаю, что TODO сделает это, если вы просто не игнорируете их.

Я программист на C++, но полагаю, что мою технику можно легко реализовать на C# или любом другом языке, если на то пошло:

У меня есть макрос ToDo(msg), который расширяется до создания статического объекта в локальной области видимости, конструктор которого выводит сообщение журнала. Таким образом, в первый раз, когда я выполняю незаконченный код, в моем журнале появляется напоминание о том, что я больше не могу откладывать выполнение задачи.

Выглядит это так:

class ToDo_helper
{
  public:
     ToDo_helper(const std::string& msg, const char* file, int line)
     {
       std::string header(79, '*');
       Log(LOG_WARNING) << header << '\n'
                        << "  TO DO:\n"
                        << "    Task:  " << msg << '\n'
                        << "    File:  " << file << '\n'
                        << "    Line:  " << line << '\n'
                        << header;
     }
};

#define TODO_HELPER_2(X, file, line) \
  static Error::ToDo_helper tdh##line(X, file, line)

#define TODO_HELPER_1(X, file, line) TODO_HELPER_2(X, file, line)
#define ToDo(X) TODO_HELPER_1(X, __FILE__, __LINE__)

... и вы используете это так:

 void some_unfinished_business() {
   ToDo("Take care of unfinished business");
 }

Это не идеальный мир, и у нас не всегда есть бесконечное время на рефакторинг или обдумывание кода.

Иногда я вставляю //REVIEW в код, если хочу вернуться к нему позже. т.е. код работает, но, возможно, не уверен, что это лучший способ.

// REVIEW - RP - Is this the best way to achieve x? Could we use algorithm y?

То же самое и с //REFACTOR

// REFACTOR - should pull this method up and remove near-dupe code in XYZ.cs

Это мой список временных тегов комментариев, которые я использую:

//+TODO  Usual meaning.
//+H     Where I was working last time.
//+T     Temporary/test code.
//+B     Bug.
//+P     Performance issue.

Чтобы указать разные приоритеты, например: //+B vs //+B+++

Преимущества:

• Легко найти / удалить код (ищите //+).
• Легко фильтровать по приоритету, например: искать //+B, чтобы найти все ошибки, искать //+B+++, чтобы получать только ошибки с высоким приоритетом.

Может использоваться с C++, C#, Java, ...

Почему обозначение //+? Потому что символ + выглядит как маленький t для временный.

Примечание: это не стандартная рекомендация, а только личная.

Вероятно, не стоит забрасывать вашу кодовую базу неинформативными TODO, особенно если у вас есть несколько участников с течением времени. Это может сбить с толку новичков. Однако мне кажется, что на практике хорошо работает - это указать автора и время написания TODO с заголовком (максимум 50 символов) и более длинным текстом.

Что бы вы ни добавили в комментарии TODO, я бы рекомендовал систематически отслеживать их. Например, есть служба, которая проверяет комментарии TODO в вашем репозитории на основе git blame (http://www.tickgit.com).

Я разработал свой собственный инструмент командной строки, чтобы обеспечить согласованный стиль комментариев TODO, используя идеи из ответов здесь (https://github.com/mristin/opinionated-csharp-todos). Было довольно легко интегрировать его в непрерывную интеграцию, так что список задач генерировался заново при каждом нажатии на мастер.

Также имеет смысл иметь список задач отдельно от вашей IDE для ситуаций, когда вы обсуждаете TODO на встрече с другими людьми, когда вы хотите поделиться им по электронной почте так далее.