Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

todos.tickgit.com

Post reply on HN
Print view View original

61–70 of 301 posts

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

#61

Post by kanox »

jbaudanza wrote: post #3

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.

> This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization.

I assign the same meaning to TODO or FIXME markers but a lot of people see this is as a measure of poor quality so instead I write regular comments of the form "this could be made better by doing X and Y".

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

#62

Post by davidlinc1 »

BurningFrog wrote: post #36
sombremesa wrote: post #23

Earlier quoted context omitted.

Pray tell, what line would you NOT put that tag on? That's like, all code...

I don't want to brag about my skills, so I won't answer that.

I similarly don't want to brag about my skills in pointing out areas of improvement in code that others might think is optimal, so I won't answer that.

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

#63

Post by kanox »

Fakira wrote: post #55
jbaudanza wrote: post #3

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.

> TODO, as the name implies, should be things that must be done.

A lot of people use them for things that "could" be done.

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

#64

Post by war1025 »

alacombe wrote: post #51
war1025 wrote: post #42

Earlier quoted context omitted.

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.

> Linux has no roadmap, no product management team scheduling features, no nothing.

I would bet large money that Linux has a great many of all three of those. They are just handled in a distributed manner by the various teams working on the different features.

Bazaar doesn't mean disorganized. It means there is no central planning authority. There are many individual planning authorities with their own agendas.

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

#65

Post by geofft »

alacombe wrote: post #44
geofft wrote: post #27

Earlier quoted context omitted.

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…

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 uncomplicated enough to go into code comments, it's definitely uncomplicated enough to go into a separate todo file, as I mentioned.

It's very straightforward to do this for documentation. Probably the right thing is to use your existing patch-contribution workflow for this, but make it lighter-weight for docs (reduced or nonexistent code review), but you can also hook up your docs to something like Ikiwiki if you prefer: being in a wiki and being in the source control repo aren't at odds with each other.

And for seeing what was in the dev's mind six months ago - use git log and git blame for that. Even TODOs get refactored away, or moved around enough that they no longer make sense. Good commit messages will show you the whole change that was being made, in context, and what the programmer was thinking when making that change.

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

#67

Post by ajmurmann »

nfoz wrote: post #19
kjs3 wrote: post #14

Earlier quoted context omitted.

Serious question as someone who drops XXX occasionally: There are all sort of places where you want to note "there's probably a better way to do this" or "maybe look at this edge case" or whatever. Not all of those are important enough to address in the next review/sprint/whatever...why isn't it better to leave them in and keep that tribal knowledge around rather that delete them and loose that insight? Maybe a bette…

I think these sorts of notes belong somewhere external of the code itself; an issue ticketing system or whatnot. Because more often than not, I find those "TODO"s lose meaning over time. They often suggest a particular way to solve something, but by the time we might come back to fixing it, that solution is no longer the best way to do it. A ticket can better express the problem , so that we can evaluate and triage h…

I very much agree that if you really want to get to the todos they should be tracked in your issue tracker and prioritized with all other work with the team. What's the alternative? Take a random afternoon to do a random Todo item instead of prioritized work?

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

#69

Post by patrickdevivo »

For anyone interested, I wrote a piece last week taking a look at the 2k+ TODOs in the Kubernetes source code as well: https://medium.com/@augmentable/looking-at-kubernetes-2k-tod...

Most were from over a year ago.

I don't think TODOs are bad practice, and I've seen a diversity of opinions on them in the comments of various posts. I think they are notoriously forgotten, and major codebases like linux and k8s are no different.

Aggressively stale TODOs though are likely an indicator of an area of code that should probably be revisited or cleaned up.

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

#70

Post by Forge36 »

war1025 wrote: 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…

TODO see issue X is also a great way to link the two together.

Is the issue still worth fixing? Well the file was completely rewritten 1 year ago, the TODO removed, and no one requesting this now/pushing for it? Close it.

Have an issue but not sure if it's relevant so it stays open forever? I've seen issues outlive the code their for by decades because investigating the lots priority issue wasn't a priority, quick "see: function" references are similar, easily searchable terms which makes old issue review very fast to close. This also ensures the backlog is reviewed periodically

Post reply on HN