How many in the Windows or Mac codebase?
The Linux codebase has over 3k TODO comments, many from over a decade ago
71–80 of 301 posts
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#72The codebase that has no TODOs has no vision of its future.
Your vision of the future should be in a bugtracker, not in code comments. TODOs give you a vision of what you would do if you had a few more hours. A bugtracker gives you a vision of what you would do if you had a few more years. (Where do you put "TODO: Learn tool X and rework all of this to be completely different using that tool if it makes sense" or even "TODO: The program crashes at shutdown with a double-free,…
I have completely the opposite opinion! Any bug in the bug tracker hanging around "in a few years" should* be closed. Comments should* persist while the source code issue to which they refer remains remarkable.
*it's fun issuing such rulings.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#73Meta: What's up this the URL on this post? The URL is just to the root of Linus' kernel repo on github, the HN sitebit is 'tickgit.com', but from the comments I figured out the actual submission is supposed to be sourcegraph.com and that nobody else seems to have any issue getting there?
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#74Earlier quoted context omitted.
Issues bugtrackers get lost, code stay. I prefer to see a TODO and have a glimpse of what was going on in the dev mind (or even my own mind, 6 months ago) rather than "hide this information for the sake of cleanliness." Just the same way, to a large extend, documentation should be in the code, not in a wiki.
Not for the sake of cleanliness - for the sake of storing the information in a useful format. If you want the bugtracker or documentation to be checked into the same source repository, that seems entirely reasonable to me. I don't know good tools beyond text files for doing this for bugtracking (although I think Fossil does this, kind of, and I'm sad that Simple Defects never took off), though if your work is uncompl…
Most devs I've been working with don't even bother with a full sentence in their commit log.
At this point, we're discussing between what "should be done" in a perfect world, and what's actually been done when you switch between a couple of project in a day, moving from "implementing feature Y" back to "putting down some random fire", back to "implementing feature X" within a day in an undermanned team. Sometime, a hack will get you back running in prod, and a "TODO" will be there next time you actually have time to address the underlying issue.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#75In my opinion, any comment prefixed by TODO, XXX, or the like should not survive past the review stage. Either fix the problem immediately or accept that it's going to be wonky forever. Edit: Amending here to avoid replying to ten different threads individually. 1. Long-term improvements should be managed by a ticket tracking system. The code is not the correct place to manage that. 2. Most of the disagreements below…
I agree with you - specifically because you said "accept that it's going to be wonky forever". The advantage of TODO/XXX/etc. is that you can grep for it. I look for it before committing, vim will syntax-highlight it as an error, etc. There's no point in grepping for every possible improvement someone might have wanted to do at some point in any part of the codebase. It's much more useful immediately. (I use XXX as a…
> something you want to do in the future.. don't put it as a code comment. File it in a bugtracker...
Comment in situ has advantages:
- preserves context without duplicating it into an external system - promotes awareness of the issue when the surrounding code is changed in future, which can lead to serendipitous resolution. - particularly useful when the issue is one of internal quality (eg coupling, duplication, missing test case) that wouldn't ordinarily qualify as a bug or proposed functional enhancement.
In contrast, the bug tracker is a graveyard where such ideas go to die.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#76I use this pattern across my codebase for the "critical functionality missing" scenario: #if DEBUG #define TODO(msg) #else #define TODO(msg) #error msg #endif Works like a charm. I've got another PRERELEASE() macro that lets you do an unofficial preview build, but would break an official stable release.
That doesn't sound like it would scale at all for any more than a couple of devs.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#77I use this pattern across my codebase for the "critical functionality missing" scenario: #if DEBUG #define TODO(msg) #else #define TODO(msg) #error msg #endif Works like a charm. I've got another PRERELEASE() macro that lets you do an unofficial preview build, but would break an official stable release.
That doesn't sound like it would scale at all for any more than a couple of devs.
Neither do TODO comments. This is just for a short-term "don't forget this piece before calling the current job done".
For anything more long-term you want to use a proper task management system with priorities, deadlines, dependencies and so on.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#78I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.
Use IMPROVEME instead of FIXME ;)
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#79Earlier quoted context omitted.
What's the advantage of throwing away context that could be useful in the future? I've taken ownership of codebases with technical debt before, and when modifying the code for something time-sensitive, I often annotate issues with the code whose solutions (usually refactoring) can't be fit into the timeline of the current project. I (or others) can then take advantage of these annotations when I have time to dedicate…
You don't throw it away, you put it in the issue tracker where it can be prioritized, tracked and categorized. If it's not worth of the issue tracker, it shouldn't be worth of a TODO either.
Eh. This is a company culture thing that depends on how you use your tracker.
At many companies, issue trackers are not used for things like "refactor this method". They're used for user-facing stories or architectural projects, and they're transparent to managers who don't want them cluttered with non-user facing stories.
I've run into managers who didn't want any TODOs in code, they wanted everything to go through the tracker. I've also run into managers that told me to stop putting everything into the tracker because they didn't know how to prioritize a random method refactor, and they felt like that information wasn't relevant to their scheduling.
I don't have a strong preference, but I lightly lean towards preferring the latter strategy. Issue trackers are slow. They are so slow, and so cumbersome, and so hard to organize, and you waste so much time linking to code files that get refactored or moved around so the context is lost. The nice thing about a TODO in code is if the method gets deleted, the TODO also gets deleted. When you're refactoring code, you don't have to go search an issue tracker and think, "wait, is there anything related to this refactor I need to update?"
If documentation is code that never gets compiled, issue trackers are like dynamically linked libraries that never actually get compiled or linked. It's very hard to keep them up-to-date; it's very hard to preserve the references.
For smaller, single-person independent projects, I don't use issue trackers. I use high-level todo lists, and all of my notes are in code next to the context they're being used for. This is because an issue tracker is just bloat for those kinds of projects.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#80In my opinion, any comment prefixed by TODO, XXX, or the like should not survive past the review stage. Either fix the problem immediately or accept that it's going to be wonky forever. Edit: Amending here to avoid replying to ten different threads individually. 1. Long-term improvements should be managed by a ticket tracking system. The code is not the correct place to manage that. 2. Most of the disagreements below…
There are times where there is no review phase. It's a single employee, trying to get something done for their employer in a reasonable amount time, usually limited by a lack of colleagues (not enough engineers) or a rapid delivery timeline. The TODO gets committed, the code is shipped to production, and the TODO comment gets no further attention.