Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Cloud Open Source Programming

Many of Kubernetes 2,000 TODO Comments Appear to Be Forgotten (medium.com) 49

Posted by EditorDavid from the not-reading-the-comments dept.
Kubernetes (originally designed by Google) is a prominent open-source container-orchestration system for cloud computing with over 4.3 million lines of Go source code. Over 700,000 lines of that code are comments.

"We've been working on a project that surfaces TODO comments in a codebase to help developers do basic project management workflows within that codebase," reads a new essay on Medium. So what did the software learn from over 2,000 TODO comments on Kubernetes? Slashdot reader patrickdevivo writes: It finds that most TODOs are quite old (average age of 2+ years) and about a quarter of them have an assignee (so they're kind of like a ticket?)

The tool used to surface the information is called tickgit, and it looks for "project management metadata" in a codebase.

The data confirms what most developers intuitively understand -- many TODO comments are forgotten and typically not addressed in a reasonable amount of time. This also appears to be the case in Kubernetes, just on a larger scale.
This discussion has been archived. No new comments can be posted.

Many of Kubernetes 2,000 TODO Comments Appear to Be Forgotten More

Many of Kubernetes 2,000 TODO Comments Appear to Be Forgotten

Comments Filter:

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

    by OrangeTide ( 124937 ) on Sunday December 22, 2019 @01:47PM (#59547898) Homepage Journal

    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.

    • Re:Our plan is to start deleting them (Score:5, Insightful)

      by lgw ( 121541 ) on Sunday December 22, 2019 @05:26PM (#59548382) Journal

      In the typical project I've worked on over the years, TODOs represent work the engineers know needs to be done, but management doesn't give us time to fix. They pile up because management never gives a shit. Management occasionally tries to impose some rule about "no TODOs in comments, make a ticket", so that they can close the tickets and sweep the problems under the rug. The big advantage of TODOs is as very useful comments to future maintainers, effectively saying "no, you're not reading the code wrong, it really is this stupid".

      Of course, I've actually worked on code that had comments that said literally that. It's remarkably useful to see a comment along the lines of "this code is a deranged hack which should be replaced ASAP" in years-old code, as you then don't rack your brains trying to figure out what important undocumented functionality the squirrels next of code implements. It lets you know up front that "it's garbage, and can be safely thrown out and replaced with something good," instead of "it looks complex because it's doing something incredibly subtle that you must preserve."

      TODOs are a weaker version of that, but still quite useful to future maintainers even if they're never acted on.

    • We have a lot of those too, and they say things like "Ask so-and-so if this is necessary" and then that person isn't around anymore, and no one has the experience to research the right answer. The joys of code from a startup where it was more important to check stuff in than to make sure it works as expected.

      • The last time I did this, I made a bug that was basically titled: "Deleting stale TODO tasks". Then I put every filename and the TODO message I found, and put it in the bug description. Now it's in our database forever and searchable and linkable. Then I deleted the original comments. I wanted to include the function I found the TODO in as well, but that was harder to automate with a simple shell script.

    • So it's like Firefox then:

      TODO: Fix memory leaks.
      TODO: Deal with browser hanging in JS.
      TODO: Fix more memory leaks.
      TODO: Fix broken printing formatting.
      TODO: Memory leaks again.
      TODO: ...

      • Re: (Score:2)

        by higuita ( 129722 )

        Do not know why people still think that firefox leaks memory... those problems were ages ago and most of then were add-on related. Since the new add-ons API and several fixes and memory rewrites, it is the browser with lower memory usage when you have several tabs open

    • I seem to recall having changed some TODOs to TODON'Ts, along with an explanation of why the TODO seemed like a good idea, but is no longer valid. Then a few months later they got deleted.

    • Re: (Score:2)

      by sad_ ( 7868 )

      I don't know if this is really the way to go.
      Don't delete them, those little todo's that are not a big a deal are ideal candidates for new people looking to contribute to oss projects.
      Instead of jumping in and immed taking on a huge task, they can cut their teeth on small todo's to solve and get familiar with the source code.

      • My problem with TODOs in the source is they are not easy to search, track, update, discuss, or prioritize. If you turn them into bugs/tickets/issues, and close most of them, you'll still be able to re-open them or sort through them and assign them. We use source control, so we don't really lose those TODOs by deleting them from the current version, they'll still exist in prior versions.

        Sadly I think many of the TODOs in projects are not small tasks. And require a fair bit of architectural understanding of t

  • TODOs are old for a reason (Score:4, Informative)

    by reanjr ( 588767 ) 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.

    • /* TODO: Check index to avoid writing outside the bounds of the buffer. */

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

      ^^^THIS times a million.

      TODOs that end up in code should result in a developer being spanked (unless they like that kind of thing).

      Whenever I see a TODO comment in code it lowers my respect for that coder, including if that coder was me.

      • Re: (Score:3)

        by swilver ( 617741 )

        Yep, better hide the problem, let's not make a future developer aware there is an issue with the code. Tickets become out of date really fast, source line numbers change, sources get completely removed (with TODO and all)... if you can even *find* a matching ticket while looking at the code... who even does that, checking if there is a ticket about said code for some method at a certain line number.

        A good TODO in the code however moves with the code, and may yet be addressed when said code is touched for s

        • Agreed. (A ticket might also be a good idea) (Score:4, Insightful)

          by raymorris ( 2726007 ) on Sunday December 22, 2019 @07:21PM (#59548610) Journal

          Agreed. If the developer is aware that functionality needs to be added later, that something is missing but not currently top priority - I'd really like to know that when I'm working on that code a year later.

          Separately, when I'm planning what the team needs to do NEXT, I look at tickets to see what needs to be done. If it's important, there should be a ticket.

          The two items are there to serve in different cases. A ticket in the system is for when we're planning our sprint / month. A comment in the code is for when somebody is working on that part of the code.

          Also ...
          Once in a while, external events (or internal screw-ups) result in situations where you have 1 week to complete 3 weeks of programming. In such cases even though you'd like to make a detailed ticket about everything you see, but that just ain't gonna happen this week.

      • Re: (Score:2)

        by higuita ( 129722 )

        both are good and should be used!

        You can quick look to the code and see the TODO about missing/incomplete features, without having to waste time digging in the ticket system about something that you don't even know that exists. TODO in the code helps read and understand the code... but fails to be useful if you already know about the problem and want to know where the problem affects the code

        Tickets are great when you already know about one problem and can search all the issues and related TODO and take car

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

      While true, I think there’s a bigger reason why they languish - they’re basically a write-off by the person who added them in the first place. It’s a tacit admission they don’t intend “to do” that task at all.

      And, as you (implicitly) touch on - the fundamental problem with TODO comments is no one will actually even see the comments until/unless that section of code gets worked on in the future. And, even then, it’s not a given the old comment will even be relevant t

      • In my experience most TODO's are along the lines of
        "TODO : better error handling" or
        "TODO : more robust logging" or
        "TODO : refactor this"
        etc. If it's about missing functionality someone is going to pick it up and the TODO becomes a DONE.
        The code works, it can be better, leave a note to come back and make it better if time allows.
        Although in some of my own personal projects I have left some TODO's which should have been DONE's, like "Encrypt this" and "Put in some fvcking error handling", but then

    • For as long as I've been programming, people have been saying "This is how things SHOULD be done", "never do it that way", "you're doing it wrong", and so forth. And yet, it happens. It's especially annoying when I ask online how to deal with X and that I can't rewrite everything and I'm told by everyone "you shouldn't do X", as if they've never dealt with the real world.

    • Re: (Score:2)

      by laffer1 ( 701823 )

      I get why you think that, but I've been burned on this. The company I work for was acquired a year ago and they're migrating us to a new jira instance. We're losing all of our old tickets. It's on us to migrate important ones, but there's hundreds to go through (at least) for each squad.

      If it's in the code, you're more likely to still have it until the code no longer matters.

    • Re: (Score:2)

      by tepples ( 727027 )

      it should be an issue in some ticketing or PM software.

      First, forking a project doesn't fork its issues. Second, where would "TODO: provision hosting for ticketing or PM software" be written?

  • Well duh. (Score:5, Interesting)

    by RyanFenton ( 230700 ) 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

    • Re: (Score:2)

      by Kjella ( 173770 )

      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

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

        • Then customers start reporting instances of "UnimplementedExceptions" that just crashed some of their production code, and the CEO is in your cube asking questions. I wish I had a thousand dollars for everytime a dev said "the tester is lying, that error can't happen!"

          • OK, fine, name the exception "CustomersFault." But have it throw that so it doesn't fail silently. And I like when the CEO comes to my cubicle (as if we were so luxurious as to have cubicles). We have a nice chat.
    • Then label it "Future: " or something more meaningful.

    • There's a snag though that I run across that this stuff is inside code that impelements a protocol that can't change (ie, networking). You can't easily reimplement it because now you're stuck reverse engineering all the quirks so that everything is 100% backwards compatible. Even if there's a bug discovered later you often have to maintain some of the behavior of the bug.

      One of my first tasks at my current job was to fix a bug due to memory alignment, yet reproduce the effects of the bug for a particular

  • TODO MyProject.
    ...
    ...
    ...
    ...
    ...
    Profit!

    Seems to be too many missing steps in this one...

  • Learn to code.

  • Is to write it down every time in a separate file, for example, source code file

  • ... is that they are absolutely valuable; however the issue is that there are almost no good business cases to address them.

    Often, TODOs point towards code that very likely needs to be re-factored, however this code is already written, tested and deployed! It may be hard to read, debug, work with, whatever; but if this code is in production, the TODO will remain in almost every scenario. Remember, refactoring code adds a lot more overhead than the work required to actually refactor the code. You may see you

  • When we decide to add new features to a particular piece of code, it almost always involves quickly reviewing existing code. There are many times where those TODOs can be brough into scope given what we are changing.

    Also, TODO statements probably could be INTERN: statements as well, because usually they are minor things that can get the intern or new guy started learning the code.

  • Well, isn't that why TODOs exist in the first place?
    I mean, on a much smaller scale project I never touch TODOs until we finally have the time to rewrite the whole shit from the ground because... you know, agile :/

  • Having lots of TODOs hanging are perfectly normal. Remember we celebrated one Mozilla had reached one million bugs milestone: https://hacks.mozilla.org/2014... [mozilla.org] . Similar logic applies here.

    Granted I work for Google, so I might be biased (but not employed in this particular project). A TODO means, I know something else needs to be added or this particular algorithm can be improved, but it is not high priority now. It might be taken care of in the next cycle (or ignored, or deleted).

    Scott Hanselman's great ta

  • I wrote a lot of TODO's in my time. When I was a newly-minted engineer, I saw every project as an opportunity to write some complex system with all the bells and whistles to show off how very very smart I was. Over time, I began to realize that the point was NOT to prove how smart I was, the point was to ship code. So I intentionally started trying to write code that did the job at hand, rather than doing the jobs I could imagine the code doing. As part of this process, I often scoped out much more in-d

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close