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

Помимо выключения "TODO": комментарий, многие IDE также выключают "ЗАДАЧУ": комментарий. Некоторый IDE, даже позволенный Вы, настраивает Ваш собственный специальный идентификатор.

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

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

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

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

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

Это три различных способа, которыми я нашел полезными для установки флага чего-то, что должно быть обращено.

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

   //TODO: Зафиксируйте это, прежде чем это будет выпущено. Это вызывает нарушение прав доступа, потому что оно использует память, которая еще не создается.

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

   международный This_Is_An_Access_Violation = 0;

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

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

// TODO: <explanation>

, если это - что-то, что я не нашел время для реализации, и не хотят забывать.

// FIXME: <explanation>

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

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

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

//TODO: Finish this

при использовании VS можно установить собственные Теги задачи под Инструментами> Опции> Среда> Список задач

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

Подход, который я действительно любил, является "Взрывом Взлома", как продемонстрировано Oren Eini здесь .

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 когда-либо уменьшаются в количестве любым значимым способом. Если у меня не было времени, чтобы сделать это, когда я записал комментарий, я не знаю, почему я имел бы время спустя.

Если я должен отбросить все посреди изменения, то

#error finish this

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

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

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

PutTheUpdateCodeHere();

//TODO: имя Человека - зафиксируйте это.

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

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

Todo комментируют также.

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

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

Я использую//TODO: или//ВЗЛОМ: как напоминание, что что-то не закончено с примечанием, объясняющим почему. Я часто (чтение 'редко') возвращаюсь и заканчиваю те вещи из-за ограничений времени. Однако, когда я просматриваю код, у меня есть запись того, что оставили незаконченным и что еще более важно ПОЧЕМУ.

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

//ЗАПУСКАЮТСЯ ЗДЕСЬ CHRIS

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

Я программист на 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");
 }

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

// TODO: Этот заем кода дает годовую процентную ставку разработчика в размере 7,5% в час. Авансовый платеж, как указано в текущей реализации. Этот контракт подлежит предварительному разрешению со стороны DCB (Developer's Code Bank), и тариф может измениться без предупреждения.

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

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

Я иногда помещаю //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