• MaxiTB (unregistered)

    The last one for sure reminds someone to replace the tertiary conditional operator with the null-coalescing operator.

  • Allie C (unregistered)

    "as someone who has recently started using Jira, some tracking tools are more garbage than others" Here here!

  • Agri (unregistered)

    On the whole, I agree that using such comments in place of a task tracking tool it doesn't make sense. Personally, I tend to use TODO comments from time to time only while working on a task. Say I have a story to implement, then there may be a reason to not implement (or fix) a certain part of the code at first - I don't know, maybe I commit the cardinal sin of hardcoding some value or local object first, before implementing getting the equivalent from a database. I would generally try to not let such comments make their way into source control though, or at least not beyond a development or feature branch, if I can help it.

    And to be fair, essentially the same requirements Remy mentions for 'good' TODO comments also apply for 'good' tasks in a tracking tool. No use dumping a quick note in a tracking tool with little or no context, only to have to discard it when you come back to it six months later because you no longer remember what you were meant to do.

  • Eric Hartwell (unregistered)

    // ToDo: WTF ? How does this even work?

    Sometimes when you're working on legacy code you run across something that apparently works but doesn't make any sense. If it's entirely unrelated to what you're working on you may not have time to figure out if it's really worth adding yet another ticket to the cleanup backlog. In this case // ToDo: WTF is a reasonable choice.

    And, of course, there's always // ToDo: OMGWTF

  • Sauron (unregistered)

    What about //FIXME comments?

    In any case, this soapbox should have been named "TODO comments considered harmful" (just like the famous "Goto statement considered harmful" article).

  • (nodebb)

    A good TODO comment has ... to capture the state of the code as it is.

    Therein lies the biggest issue with TODO comments. I frequently come across TODO comments that no longer apply because somebody has done the thing but not removed the comment. I used to have a script that searched for TODO comments in my code and emitted a message that was crafted to look like a compiler warning so my IDE could flag them and highlight them. But now, I think it is a better idea to ban them altogether and create tickets in your issue tracking system instead.

  • (nodebb) in reply to Allie C

    Just for kicks, open the developer toolbar in your browser, switch to network tab, and filter to only XHRs. Then open any Jira page, like an issue.

    Addendum 2022-09-20 08:38: PS. Do it using either server or cloud version, but especially cloud version.

  • Daniel Orner (github) in reply to Mr. TA

    Holy crap I did not expect this to be that amazing. You've got the same XHR request multiple times, you've got a bunch of different requests to the same graphQL endpoint (and isn't the whole point of GraphQL to ask exactly what you want so you don't have to make multiple requests?)

    This is my favorite though:

    POST https://REDACTED.atlassian.net/rest/internal/2/log/safe/info

    ...Yes, they have an XHR endpoint to log some information. Well... maybe the backend is doing other stuff as well, in which case why is this called "log"?

    Funnily enough I quite like using Jira, perhaps because someone else handles all the administration parts of it. I guess you can't possibly get something this complex without it being a giant ball of WTFs though.

  • (nodebb)

    Just many IDE's flag //TODO specifically, they should be easily surfaced during code review (such as when a PR is done). Then it can be validated that they contain desired details (or link to some external item such as a Jira Ticket that does). Why blame the comment, when the issue seems to be with the people (beyond the person who wrote it) who are involved in the process????

  • Ollie Jones (unregistered)

    I rig my IDEs to recognize //HACK HACK as a synonym for //TODO. Then, when I'm trying to get stuff working and I need a temporary stub or bogus code it gets tagged HACK HACK.

    There's a big incentive not to push code with HACK HACK still in it: coworkers make fun of me.

  • (nodebb) in reply to Jeremy Pereira

    But now, I think it is a better idea to ban them altogether and create tickets in your issue tracking system instead.

    I would have said "as well", with some caveats about at least putting in a minimum amount of info in the comment, so that someone who visits the code for other reasons might be able to see that "Oh, hey, if I do this change that I'm working on, the reason this comment is a TODO will cease to exist, better update the referenced ticket".

    Well, except that the ticket in question was rendered inaccessible by not the last migration of ticket systems, but the one before that. We have a similar problem in that old tickets in Mantis (we're part way through a migration to Jira) often refer to code reviews posted in the previous review system, or even the one before that, so it's impossible to see what reviewers said about the code back then.

  • Barry Margolin (github)

    I mainly use TODO when I'm doing incremental development, to keep track of the parts I haven't gotten to yet. I have an application whose main loop is a big switch/case. I created all the cases first, i initializing them all with //TODO until I filled them in.

    But our codebase is littered with old TODOs from my boss for future plans/fixes.

  • Sole Purpose Of Visit (unregistered)

    There is a huge operational difference between "TODO: I am lazy and/or an imbecile" and "TODO: I'm in the middle of refactoring this mess."

    So, no. I do not consider TODOs evil. Even in cases where they are dubious.

  • Zygo (unregistered)

    Don't forget the TODO-assert:

    // note this is the complete example, if built with NDEBUG we just keep going. if (n % 2) assert(!"TODO: no implementation for cases where n is odd");

    and the TODO-log:

    log_debug("TODO: not implemented");

  • Randal L. Schwartz (google) in reply to Allie C

    "as someone who has recently started using Jira, some tracking tools are more garbage than others" Here here!

    Agreed.

    And I guess you won't be looking for Atlassian as a sponsor anytime soon. :)

  • Zygo (unregistered)

    I have seen an assortment of tools that highlight TODO/FIXME/XXX comments, and in some cases add them to project metrics ("change XYZ-123 adds 3 new FIXME comments, the total is now 864").

    I've seen one or two small projects that were brave enough to use precommit hooks to block TODO comments. Those projects had lots of "TWODEW" and "REPAIRMYSELF" and "ATTN" comments, and there was a short arms race between the automated hooks and developers' creative spelling and phrasing before the whole idea was dropped. Coders gonna TODO, it's what they do.

    The idea of a "TODO scrub" comes up from time to time. Scan code for TODO comments and then put them in a proper PR tracking system so they can be assessed and ignored through the official process. Somehow the task for implementing the TODO scrub process never gets enough priority for anyone to work on making it happen.

  • (nodebb)

    If you think "TODO" is bad, just remember that when you get home, there's a "Honeydew" list for you. Probably long, and certainly grave danger awaits if you don't get it done..

  • a cow (not a robot) (unregistered)

    // TODO: write a comment here.

  • Yikes (unregistered)

    Great idea to get rid of TODO's: just force whoever wants to enter them to pass through TDWTF's captcha filter first!

  • (nodebb) in reply to Daniel Orner

    Holy crap I did not expect this to be that amazing. You've got the same XHR request multiple times, you've got a bunch of different requests to the same graphQL endpoint (and isn't the whole point of GraphQL to ask exactly what you want so you don't have to make multiple requests?)

    The system I'm working on also has redundant requests, so that we don't have to have a God Object passed all over the webpage; separate sections of the page that need semi-similar info don't need to have a coordinator passing things around.

    The difference is that my system is heavily cached for these sorts of things, both client-side and server-side. When three different components need the same info blob (usually using different parts of that blob), only one "real" request gets made. I can only hope that Jira is half as good about caching.

  • Steve W (unregistered) in reply to Zygo

    "Somehow the task for implementing the TODO scrub process never gets enough priority for anyone to work on making it happen." Obviously you need to add this as a TODO in the code. Problem solved.

  • (nodebb) in reply to PotatoEngineer

    Basically you still have a "god object" but it happens to be managed by the browser cache. The downside is that you still have overhead of the request creation and such (even with in-memory cache response) which is CPU and memory usage, and every time the request gets the data from cache, it is converted to JS data anew, which is again more CPU and memory usage. If I was you, I would create a "common data manager" which provides async (Promise-returning) methods to get common data, and negates the reason for multiple requests (cached or not).

  • Chris (unregistered)

    It seems to me that the main problem is that a "TODO" comment implies a process that ensures those parts of the code will be revisited in the future. Hence the recommendation to use an actual task-tracking process, since a comment doesn't ensure anything gets done. What a TODO does do is provide a bookmark, nothing more.

  • (nodebb)

    I used to be bad about leaving TODOs behind. Nowadays I reserve them for incremental development, such as when the code to display a list of widgets is completed, but:

    function updateWidget() {
    // TODO implement this
    bootbox.alert("Not yet implemented");
}

    and use "// Future improvement: (thing)" or "// Possible future improvement: (thing)" for nice-to-haves that aren't worth clogging up our already-bloated backlog, but if/when a specific reason to implement it does arise, then I or another dev will likely come across the comment again at that point.

  • Tim (unregistered)

    One thing I've learned on many projects over many years is that ticketting systems, documents, and wikis come and go, but the code remains. That's why I try to put as much documentation as possible inside the code. Revision control is the exception though - that's something you just can't do with comments.

  • (nodebb) in reply to Steve_The_Cynic

    Well, except that the ticket in question was rendered inaccessible by not the last migration of ticket systems, but the one before that.

    It's OK, if you hang on long enough it'll come around again. There are tickets in our backlog that were raised in Jira, then migrated to Asana when we decided we would use that instead, then migrated back to Jira (in a different project) when we changed our minds again. Of course if you didn't migrate your outstanding tickets to your new system then you are TRWTF.

    If you keep the list of previous ticket IDs in a comment on the ticket, you can still locate it eventually :)

  • (nodebb)

    I used to use Jira about 7 years ago. Maybe things have changed since then. But back then... I didn't enjoy it. It was slow and the UI was clunky. However, after seeing other systems, they all left me wanting for something that Jira had. Like the way you could cross-link tickets and have workflows implemented. As much as I don't like Jira, I have to begrudgingly admit that they were good at what they were doing. Just... not very polished.

  • (nodebb)

    I'd distinguish three kinds of TODOs.

    The first one is a TODO intended to be handled by the same person that put it there. A booknote marking a place that needs more changes to implement the feature/request that I'm working on, but it's the kind of change I did not get around to yet. I just don't want to have to search for the place again. It might end up in an interim commit, but definitely not in a pull request.

    The second is a TODO similar to the @JoebobBobsen one in the article. A TODO intended as a question to the guy(s) doing the code review. One that's supposed to be handled by adding a comment to the pull request rejection. You don't always have Mr. Bobsen around to ask him directly and shooting him an email detailing the location of the problematic passage in the codebase would waste way more of both your and his time. Though it does assume code reviews are actually being done and a pull request with one of there will not get approved.

    Only the third case needs all those three pieces of information and may end up in the main branch ... and even then it does make sense to add a ticket for the task in whatever system you use, with the proper priority and the ID of the ticket included in the TODO.

  • shcode (unregistered)

    i use todos only in personal projects, and only for task tracking - "this needs to be implemented but i don't want to do it right now".

    that way, when i open the project later because i want to work on it but don't have anything specific in mind to work on, i just search for the todos, and pick something from the results.

  • (nodebb)

    Remy forgot to do his own TODO and didn't post an article :)

  • Gorledge (unregistered) in reply to MaxiTB
    Comment held for moderation.
  • xtal256 (unregistered) in reply to Agri
    Comment held for moderation.
  • dereferenced null pointer (unregistered)

    // TODO: do the do you're told to do

  • that's right (unregistered)
    Comment held for moderation.
  • mk guru (unregistered)
    Comment held for moderation.
  • Craig (unregistered)
    Comment held for moderation.
  • (nodebb)

    "TODOs are a code smell"

    Of course they are, that's the point of them - to raise a smell that might otherwise not get noticed.

    TODOs should break the build on the main branch, but not on others.

Leave a comment on “TODO: Post an Article”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article