1

Statement

I often find myself still writing the following statement all over my code:

// TODO: (the work that needs done)

I do this in order to flag that I need to come back and do something later on. It often happens when the functionality of the code is dictated by other code that will be written later on. I did a quick Google search and took the first two results about this...

The first result I found explains that this is a valid way of doing things, and is the first result that shows up in Google:

How do you flag code...

Then, another result I found suggested something about that a Task List could be used as an alternative...

Creating Task Lists with Visual Studio...

The problem I have with both of these is that they are both 7+ years old, and I am exploring what has changed between now and then.

Question

Is writing TODO, still a valid way of doing things?

Improve this question
10
  • 2
    Do you have a way of efficiently revisiting those places? If yes, then it's a workable solution. For instance, Eclipse automatically adds lines marked like this into its task list - it doesn't get any more automatic than that.
    – Kilian Foth
    Apr 26, 2016 at 12:46
  • I've been doing that lately. We'll see how it turns out. :)
    – MetalMikester
    Apr 26, 2016 at 12:48
  • @MetalMikester Yeah, it seems as though either doing it this way, or by TDD would be good ways to track what needs done next.
    – Snoop
    Apr 26, 2016 at 12:51
  • 2
    Something that I've seen used to great effect is gated check-ins looking for TODO code. If it finds the phrase in a comment, source control won't allow check-ins. It's a good way to make sure you don't accidentally check in testing code.
    – mgw854
    Apr 26, 2016 at 12:51
  • @mgw854 Never heard of that, so the VCS actually looks for the TODO and won't allow check-in? That gives me the incentive to keep doing it this way.
    – Snoop
    Apr 26, 2016 at 12:52

1 Answer 1

Reset to default
2

If you are into TDD, I suggest you write up a test which will fail until the functionality gets implemented.

The only downside I can see is if you are a somewhat lazy function such failing tests will contribute a lot of noise to runs and may hide actual failures behind all that.

Improve this answer
1
  • 2
    That's really not a bad idea. Until the other day I didn't know what TDD actually was, but yeah I started writing the tests then defining library functions later that would adhere to those tests. I guess I could do the same thing for my application code where I would need to write a TODO.
    – Snoop
    Apr 26, 2016 at 12:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.