The Linux codebase has over 3k TODO comments, many from over a decade ago • Hacker News Board

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

#11

Post by slimsag » Mon, Dec 30, 2019, 3:07 AM UTC

Interesting! I got curious about where they come from, so I dug a little. Here is a non-exhaustive breakdown:

- 23 from crypto code: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

- 2380 from driver code: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

- 73 from ARM arch code: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

- 43 from x86 arch code: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

- 114 from other arch code: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

- 606 from block IO, FS, networking, and other sources: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

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

#12

Post by juniorplenty » Mon, Dec 30, 2019, 3:08 AM UTC

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…

Disagree. There are lots of reasons TODOs live on, mostly having to do with stashing ideas that aren’t functionally critical, or pointers for future devs who might inherit the codebase without immediately grokking a performance optimization or corner case that occurred to the previous owner, but wasn’t important enough to deal with at that time. Sometimes, they just save face for the original dev who would love to make something better, but had to move.

Black-and-white rules like “No TODOs after review!!” are not only too trivial to enforce for a real production team working on deadline, they remove the soft fuzzy subjective edges that make what we do art, not math.

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

#13

Post by fogetti » Mon, Dec 30, 2019, 3:08 AM UTC

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…

I am hesitant to write this, because in general I agree, but let's say a product manager stops a feature short of completed in some sense, even though there are some aspects which would make the feature more robust, secure or optimized, the code gets released and one would need a tombstone as a visible nuisance and indicator for these aspects, wouldn't it?

I mean the best place to communicate important ideas and warnings about code, is the code itself isn't it?

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

#14

Post by kjs3 » Mon, Dec 30, 2019, 3:08 AM UTC

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…

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 better question: is there a better way to collect those sorts of low priority tasks?

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

#15

Post by namirez » Mon, Dec 30, 2019, 3:08 AM UTC

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, XXX, or the like should not survive past the review stage

I'm afraid if you stick to this principle, you will never have any code ready for review. Using TODO is not an excuse for writing buggy code, but an indication of future improvements and optimizations.

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

#16

Post by kjs3 » Mon, Dec 30, 2019, 3:11 AM UTC

Fiaxhs wrote: post #8

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.

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

That seems like a good compromise. I've used LOOKAT to note places where I got things going but felt like there was a better way of doing things if I had more time.

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

#17

Post by jniedrauer » Mon, Dec 30, 2019, 3:11 AM UTC

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…

Having some way to designate that you're not happy with the code, but it works, is valuable for future refactoring. Another one I see a lot is some variation of "this is a hack." Grepping for "hack" in a codebase can be very entertaining. TODO is more to the point though.

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

#18

Post by shp0ngle » Mon, Dec 30, 2019, 3:14 AM UTC

The number of FIXMEs seems about half of that, from a quick glance.

FIXMEs : https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...

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

#19

Post by nfoz » Mon, Dec 30, 2019, 3:15 AM UTC

kjs3 wrote: post #14

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…

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 how serious that problem is, and when the time comes to fix it often we'll come up with a better solution than the TODO would have expressed.

A FIXME is even more obvious: if something needs to be fixed, then let's track an issue/ticket for it, otherwise noone will ever know to fix it.

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

#20

Post by BurningFrog » Mon, Dec 30, 2019, 3:15 AM UTC

Fiaxhs wrote: post #8

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.

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

To me, FIX implies that something is wrong, not that it works but could use improvement.

I would like to have a tag for "here's something that works, but could be improved" though!