Live data from Hacker News

The Linux codebase has over 3k TODO comments, many from over a decade ago

todos.tickgit.com

51–60 of 301 posts

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#51
post #42

Earlier quoted context omitted.

And your kernel would likely never ship, at least not with many drivers anyways. Don't forget Linux is largely a grassroots effort with heaps of reverse-engineered or otherwise improvised/ad-hoc hardware enablement going on. It wasn't until relatively recent history that we could even suspend/resume reliably!

Some form of tracking tool is the correct place to document the roadmap, in my opinion. The roadmap can be continuously monitored and updated. TODOs in code just end up as comments that exist for a decade because no one along the way wants to delete them, even if they have no relevance anymore.

Even though "mainline" has been structuring a tad over the past 5 years or so, Linux has no roadmap, no product management team scheduling features, no nothing. It is the epitome of bazaar development model done over mailing lists... and it's been working pretty well.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#52
post #45

Earlier quoted context omitted.

So that it's grep-able?

It's also nice to highlight TODO and FIXME in your text editor for added emphasis. I believe Vim even does this by default.

I think this is the primary benefit.

Only so many times can you scroll past a nagging ide hint before you say "FINE, I guess I'll do it now!"

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#53
post #2

In 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…

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.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#54
post #25

The codebase that has no TODOs has no vision of its future.

I don't think TODO should be utilized for future functionality but for improvements in existing functionality or things that are missing in the current implementation you can live with short term.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#55

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

TODO, as the name implies, should be things that must be done. Anything aspirational could be left as a mere ordinary comment.

Personally I hate TODOs and only see them as temporary things to act as placeholders for the correct code. At some point, I will go through all todos and clear them.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#56
post #2

In 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…

Let us know when you ship your perfect alternative to Linux.

That is an uncharitable interpretation of what I wrote, and I suspect you know that.

"Many over a decade old" fits pretty directly with what I wrote. TODOs are where good intentions go to die. They get added and rarely addressed or removed.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#57
post #2

In 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…

This may sound weird but I use TODO's to document things I expect to be wonky forever or at least for a very long time.

Things I actually intend to fix go in the tracker.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#58
post #2

In 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…

Doesn't that just fall under the "don't let perfect be the enemy of good" ethos?

I amended my comment to hopefully be more clear about the point I intended to convey.

And as with all advice, it shouldn't be followed blindly.

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#59
post #9

> The Linux codebase has over 3k TODO comments, many from over a decade ago And that is ok.

Sure, for the individual. Does the project track them internally? How are they followed up on? How is work assigned and prioritized?

When the file is next edited by the next individual. They don't need to be tracked

Re: The Linux codebase has over 3k TODO comments, many from over a decade ago

#60
post #8

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

Correct me if I'm wrong but I use "FIXME" for this intent. I keep TODO for stuff actually left to implement.

Is there a standard for valid flags? I recently recommended a client use `TODOSECURITY` for todos which had security implications until fixed - I discovered functionality which was implemented before authorisation had been developed, resulting in a codepath which was unintentionally reachable by standard users.

Seemed weird to make up a codeword but I wasn't aware of any standard convention, and visually highlighting high impact issues (w/ the bonus of greppability) seemed like a sane approach in rapid development environments.

Post reply on HN