How do you flag code so that you can come back lat

问题:

In C# I use the #warning and #error directives,

#warning This is dirty code...
#error Fix this before everything explodes!

This way, the compiler will let me know that I still have work to do. What technique do you use to mark code so you won't forget about it?

回答1:

Mark them with // TODO, // HACK or other comment tokens that will show up in the task pane in Visual Studio.

See Using the Task List.

回答2:

Todo comment as well.

We've also added a special keyword NOCHECKIN, we've added a commit-hook to our source control system (very easy to do with at least cvs or svn) where it scans all files and refuses to check in the file if it finds the text NOCHECKIN anywhere.

This is very useful if you just want to test something out and be certain that it doesn't accidentaly gets checked in (passed the watchful eyes during the diff of everything thats commited to source control).

回答3:

I use a combination of //TODO: //HACK: and throw new NotImplementedException(); on my methods to denote work that was not done. Also, I add bookmarks in Visual Studio on lines that are incomplete.

回答4:

//TODO: Person's name - please fix this.

This is in Java, you can then look at tasks in Eclipse which will locate all references to this tag, and can group them by person so that you can assign a TODO to someone else, or only look at your own.

回答5:

'To do' comments are great in theory, but not so good in practice, at least in my experience. If you are going to be pulled away for long enough to need them, then they tend to get forgotten.

I favor Jon T's general strategy, but I usually do it by just plain breaking the code temporarily - I often insert a deliberately undefined method reference and let the compiler remind me about what I need to get back to:

PutTheUpdateCodeHere();

回答6:

If I've got to drop everything in the middle of a change, then

#error finish this

If it's something I should do later, it goes into my bug tracker (which is used for all tasks).

回答7:

Add a test in a disabled state. They show up in all the build reports.

If that doesn't work, I file a bug.

In particular, I haven't seen TODO comments ever decrease in quantity in any meaningful way. If I didn't have time to do it when I wrote the comment, I don't know why I'd have time later.

回答8:

An approach that I've really liked is "Hack Bombing", as demonstrated by Oren Eini here.

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;
}

回答9:

//TODO: Finish this

If you use VS you can setup your own Task Tags under Tools>Options>Environment>Task List

回答10:

gvim highlights both "// XXX" and "// TODO" in yellow, which amazed me the first time I marked some code that way to remind myself to come back to it.

回答11:

I use // TODO: or // HACK: as a reminder that something is unfinished with a note explaining why. I often (read 'rarely') go back and finish those things due to time constraints. However, when I'm looking over the code I have a record of what was left uncompleted and more importantly WHY.

One more comment I use often at the end of the day or week:

// START HERE CHRIS

^^^^^^^^^^^^^^^^^^^^ Tells me where I left off so I can minimize my bootstrap time on Monday morning.

回答12:

It's not a perfect world, and we don't always have infinite time to refactor or ponder the code.

I sometimes put //REVIEW in the code if it's something I want to come back to later. i.e. code is working, but perhaps not convinced it's the best way.

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

Same goes for //REFACTOR

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

回答13:

Todo Comment.

回答14:

// TODO: <explanation>

if it's something that I haven't gotten around to implementing, and don't want to forget.

// FIXME: <explanation>

if it's something that I don't think works right, and want to come back later or have other eyes look at it.

Never thought of the #error/#warning options. Those could come in handy too.

回答15:

I use //FIXME: xxx for broken code, and //CHGME: xxx for code that needs attention but works (perhaps only in a limited context).

回答16:

These are the three different ways I have found helpful to flag something that needs to be addressed.

1. Place a comment flag next to the code that needs to be looked at. Most compilers can recognize common flags and display them in an organized fashion. Usually your IDE has a watch window specifically designed for these flags. The most common comment flag is: //TODO This how you would use it:

   //TODO: Fix this before it is released. This causes an access violation because it is using memory that isn't created yet.

2. One way to flag something that needs to be addressed before release would be to create a useless variable. Most compilers will warn you if you have a variable that isn't used. Here is how you could use this technique:

   int This_Is_An_Access_Violation = 0;

3. IDE Bookmarks. Most products will come with a way to place a bookmark in your code for future reference. This is a good idea, except that it can only be seen by you. When you share your code most IDE's won't share your bookmarks. You can check the help file system of your IDE to see how to use it's bookmarking features.

回答17:

If it's some long term technical debt, you can comment like:

// 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.

... err. I guess a TODO will do it, as long as you don't simply ignore them.

回答18:

I'm a C++ programmer, but I imagine my technique could be easily implemented in C# or any other language for that matter:

I have a ToDo(msg) macro that expands into constructing a static object at local scope whose constructor outputs a log message. That way, the first time I execute unfinished code, I get a reminder in my log output that tells me that I can defer the task no longer.

It looks like this:

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__)

... and you use it like this:

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

回答19:

I also use TODO: comments. I understand the criticism that they rarely actually get fixed, and that they'd be better off reported as bugs. However, I think that misses a couple points:

• I use them most during heavy development, when I'm constantly refactoring and redesigning things. So I'm looking at them all the time. In situations like that, most of them actually do get addressed. Plus it's easy to do a search for TODO: to make sure I didn't miss anything.

• It can be very helpful for people reading your code, to know the spots that you think were poorly written or hacked together. If I'm reading unfamiliar code, I tend to look for organizational patterns, naming conventions, consistent logic, etc.. If that consistency had to be violated one or two times for expediency, I'd rather see a note to that effect. That way I don't waste time trying to find logic where there is none.

回答20:

As most programmers seem to do here, I use TODO comments. Additionally, I use Eclipse's task interface Mylyn. When a task is active, Mylyn remembers all resources I have opened. This way I can track

1. where in a file I have to do something (and what),
2. in which files I have to do it, and
3. to what task they are related.

回答21:

Besides keying off the "TODO:" comment, many IDE's also key off the "TASK:" comment. Some IDE's even let you configure your own special identifier.