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.
The Linux codebase has over 3k TODO comments, many from over a decade ago
51–60 of 301 posts
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#52Earlier 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.
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
#53In 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…
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#54The codebase that has no TODOs has no vision of its future.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#55I 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.
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
#56In 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.
"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
#57In 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…
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
#58In 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?
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> 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?
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#60I 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.
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.