В С# я использую директивы #warning и #error,
#warning This is dirty code...
#error Fix this before everything explodes!
Таким образом, компилятор сообщит мне, что у меня все еще есть работа. Какую технику вы используете для обозначения кода, чтобы вы не забыли об этом?
Отметьте их // TODO, // HACK или другими токенами комментариев, которые будут отображаться на панели задач в Visual Studio.
Комментарий Todo.
Мы также добавили специальное ключевое слово NOCHECKIN, мы добавили фиксацию фиксации в нашу систему управления версиями (очень легко сделать, по крайней мере, cvs или svn), где он сканирует все файлы и отказывается проверять файл если он найдет текст NOCHECKIN в любом месте.
Это очень полезно, если вы просто хотите что-то проверить и быть уверенным, что он случайно не проверяется (передал бдительные глаза во время разброса всего, что было поручено контролю источника).
Я использую комбинацию //TODO: //HACK: и throw new NotImplementedException(); для моих методов, чтобы обозначить работу, которая не была выполнена. Кроме того, я добавляю закладки в Visual Studio на незавершенные строки.
//TODO: имя человека - исправьте это.
Это в Java, вы можете посмотреть задачи в Eclipse, которые найдут все ссылки на этот тег и могут группировать их по человеку, чтобы вы могли назначить TODO кому-то другому или посмотреть только на свой.
Если мне нужно сбросить все в середине изменения, то
#error finish this
Если это то, что я должен сделать позже, оно переходит в мой трекер ошибок (который используется для всех задач).
"Делать" комментарии велики в теории, но не настолько хороши на практике, по крайней мере, в моем опыте. Если вас уволят надолго, чтобы они нуждались в них, то они, как правило, забываются.
Я одобряю общую стратегию Jon T, но я обычно делаю это, просто временно нарушая код временно - я часто вставляю преднамеренно undefined метод ссылки и пусть компилятор напоминает мне о том, что мне нужно, чтобы вернуться к:
PutTheUpdateCodeHere();
Добавьте тест в отключенное состояние. Они отображаются во всех отчетах о создании.
Если это не сработает, я создаю ошибку.
В частности, я не видел, чтобы комментарии TODO когда-либо уменьшались количественно каким-либо значимым образом. Если бы у меня не было времени на это, когда я написал комментарий, я не знаю, почему у меня было бы время позже.
Подход, который мне действительно понравился, - "Hack Bombing", как показано 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: Finish this
Если вы используете VS, вы можете настроить свои собственные теги задач в разделе Инструменты > Параметры > Средa > Список задач
gvim выделяет как "//XXX", так и "//TODO" желтым цветом, что поразило меня в первый раз, когда я обозначил некоторый код, чтобы напомнить себе, чтобы вернуться к нему.
Я использую //TODO: или//HACK: как напоминание о том, что что-то не завершено запиской, объясняющей почему. Я часто (читаю "редко" ) возвращаюсь и заканчиваю это из-за ограничений по времени. Однако, когда я просматриваю код, у меня есть запись того, что осталось незавершенным и, что более важно, ПОЧЕМУ.
Еще один комментарий, который я часто использую в конце дня или недели:
//НАЧАТЬ ЗДЕСЬ CHRIS
^^^^^^^^^^^^^^^^^^^^ Сообщает мне, где я остановился, поэтому я могу свести к минимуму время загрузки в понедельник утром.
Это не идеальный мир, и у нас не всегда есть бесконечное время для рефакторинга или размышления над кодом.
Я иногда помещаю //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.
// TODO: <explanation>
если это то, что я не получил, чтобы реализовать, и не хочу забывать.
// FIXME: <explanation>
если это то, что я не думаю, правильно работает, и хочу вернуться позже или посмотреть на него другими глазами.
Никогда не думал о параметрах # ошибки /# предупреждения. Это может пригодиться.
Я использую //FIXME: xxx для неработающего кода и //CHGME: xxx для кода, который требует внимания, но работает (возможно, только в ограниченном контексте).
Вот три разных способа, которые я нашел полезными, чтобы отметить что-то, что нужно решить.
Поместите флаг комментария рядом с кодом, который нужно посмотреть. Большинство компиляторов могут распознавать общие флаги и отображать их организованно. Обычно у вашей IDE есть окно с часами, специально предназначенное для этих флагов. Наиболее распространенным флагом комментариев является://TODO. Как вы его используете:
//TODO: исправить это, прежде чем он будет выпущен. Это приводит к нарушению доступа, поскольку оно использует еще не созданную память.
Один из способов отметить то, что нужно решить перед выпуском, - создать бесполезную переменную. Большинство компиляторов предупредит вас, если у вас есть переменная, которая не используется. Вот как вы могли бы использовать эту технику:
int This_Is_An_Access_Violation = 0;
Закладки для IDE. Большинство продуктов будут поставляться с возможностью размещения закладки в вашем коде для дальнейшего использования. Это хорошая идея, за исключением того, что ее можно увидеть только вы. Когда вы делитесь своим кодом, большинство IDE не будут делиться вашими записями. Вы можете проверить файловую систему справки вашей среды 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 Code Bank), and tariff may change without warning.
... err. Я думаю, что TODO сделает это, пока вы не просто игнорируете их.
Я программист на С++, но я полагаю, что моя техника может быть легко реализована на С# или любом другом языке:
У меня есть макрос 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: комментарии. Я понимаю критику, что они редко на самом деле фиксируются, и что им лучше сообщать об ошибках. Тем не менее, я думаю, что пропустил пару очков:
Я использую их больше всего во время тяжелого развития, когда я постоянно реорганизую и перепроектирую вещи. Поэтому я постоянно смотрю на них. В подобных ситуациях большинство из них действительно обращаются. Кроме того, легко выполнить поиск TODO: убедиться, что я ничего не пропустил.
Это может быть очень полезно для людей, читающих ваш код, чтобы узнать, какие пятна вы считаете плохо написанными или взломанными вместе. Если я читаю незнакомый код, я, как правило, ищу организационные шаблоны, соглашения об именах, согласованную логику и т.д. Если эта последовательность должна была быть нарушена один или два раза для целесообразности, я бы предпочел увидеть заметку об этом. Таким образом, я не теряю времени, пытаясь найти логику там, где ее нет.
Как и большинство программистов, я использую комментарии TODO. Кроме того, я использую интерфейс задач Eclipse Mylyn. Когда задача активна, Mylyn запоминает все ресурсы, которые я открыл. Таким образом, я могу отслеживать
Помимо включения комментария "TODO:", многие IDE также отключают комментарий "ЗАДАЧА:". Некоторые IDE даже позволяют настроить собственный специальный идентификатор.