×

• Our plan is to start deleting them (Score:1)

  by OrangeTide ( 124937 ) writes:

  Our project (related to Kubernetes) has a lot of these TODOs. We’ve put them in a list and starting next year we will erase the comments that are too low priority to conceivably ever receive attention. The threshold for that is if we think it would take so long to address the TODO that architectural changes are likely to occur and make it irrelevant.
• TODOs are old for a reason (Score:3)

  by reanjr ( 588767 ) writes: on Sunday December 22, 2019 @01:48PM (#59547900) Homepage

  If something is important for the functionality of the software, it shouldn’t be a TODO in the code, it should be an issue in some ticketing or PM software. TODOs that end up in code should be expected to languish, as we already know they are not important to the functionality of the software.

  But that doesn’t mean they aren’t useful. At the very least they describe some bit of missing behavior that may be relevant to someone coming in to change the behavior later.

  Nothing to see here.

  Reply to This Share

  twitter facebook linkedin

  Flag as Inappropriate
• Well duh. (Score:3)

  by RyanFenton ( 230700 ) writes: on Sunday December 22, 2019 @01:50PM (#59547904)

  TODO comments are inherently aspirational.

  They’re notes to your future self, that if you want to generalize this code, to make it more useful than it’s immediate self, then here’s what you intended the more full version of this code to do.

  But most of that code ends up being as trivial to re-create than it would be to look up again.

  Still though, the TODOs are useful landmarks in the code space. Your eye gets used to seeing them when scanning or searching through the bulk code. Like writing down notes in class the act of making them, then glancing across them again puts you back in that mindset faster than otherwise.

  Intentions change, priorities change. There’s very rarely a coding project where you don’t learn something important that you can apply the next go-around at a task – so your aspirations also change.

  TODO: Add examples to this post.

  Ryan Fenton

  Reply to This Share

  twitter facebook linkedin

  Flag as Inappropriate

  • Re: (Score:2)

    by Kjella ( 173770 ) writes:

    TODO comments are inherently aspirational. They’re notes to your future self, that if you want to generalize this code, to make it more useful than it’s immediate self, then here’s what you intended the more full version of this code to do.

    Sometimes it’s also more or less a requirement to build the API right, if you have options A and B but know that A+B is possible but out of scope the right way is:

    func( bool a, bool b):
    if ( a and b ) { /* TODO: Implement me */ return false; }

    and not mangle it into one bool even though right now it’s a or b. Maybe it’s not ever going to become relevant but fleshing out the function call and leaving a TODO as a placeholder. Same thing with things that in idealized code should be configurable but you’re just g

    • Re: (Score:2)

      by phantomfive ( 622387 ) writes:

      Raise an UnimplementedException. That way the TODO becomes superfluous, and someone won’t be calling func() over and over wondering why it’s always returning false.
  • Re: (Score:2)

    by phantomfive ( 622387 ) writes:

    Then label it “Future: ” or something more meaningful.

There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.