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

271–280 of 301 posts

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

#271

Post by jwiley »

I used to be pro-TODO, I find myself today firmly in the no-TODO camp.

I work daily on a large, mature code-base, littered with cryptic TODOs left by developers long-gone. They are generally as useful as street-signs in a ghost town.

TODO: clean this up

toDo: validate once ARF-211 is closed

todo remove

TODO factor

TODO: lol, hae to enable in production for some reason

TODO- will this scale? logarithmic?

If I dive into the commit logs, I can try and sus out why they were there, whether they can be removed or acted on. Generally other devs don't touch them out of superstition, they are probably there for a reason, someone else understands them, and they will eventually be useful.

Clearly, better team agreements, discipline, strict code reviews etc could have prevented this or made them more useful, but that ship had sailed before I arrived, and given the pace of maintenance and new feature development I am sure these TODOs will remain for quite some time...monuments to earlier days and priorities that are long gone.

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

#272

Post by shantly »

rumanator wrote: post #122
yongjik wrote: post #38

Earlier quoted context omitted.

That's a terrible advice. When I worked at Google, many code reviews added more TODOs because the reviewer identified a potential source of problem but also correctly decided that fixing it right there was not the best use of developers' time. When code has potential issues, I want it to be marked with TODO which basically says "The original developer was not an idiot, but was working with limited resource and the be…

> That's a terrible advice. When I worked at Google, many code reviews added more TODOs because the reviewer identified a potential source of problem but also correctly decided that fixing it right there was not the best use of developers' time. I'm sure Google is able to adopt a working ticketing system. If you already have an issue tracker then it makes absolutely no sense to keep a separate out-of-band ticketing r…

> I'm sure Google is able to adopt a working ticketing system. If you already have an issue tracker then it makes absolutely no sense to keep a separate out-of-band ticketing repository such as source code sprinkled with TODO entries.

We don't need any comments, then, if we have documentation. Right?

My point is they're not the same thing and don't serve the same purpose. A TODO comment is not the same thing as an issue. The audience is, or should be, different, as is the context.

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

#273

Post by lucideer »

jwiley wrote: post #271

I used to be pro-TODO, I find myself today firmly in the no-TODO camp. I work daily on a large, mature code-base, littered with cryptic TODOs left by developers long-gone. They are generally as useful as street-signs in a ghost town. TODO: clean this up toDo: validate once ARF-211 is closed todo remove TODO factor TODO: lol, hae to enable in production for some reason TODO- will this scale? logarithmic? If I dive int…

Your anecdotes are familiar and I completely agree with some of your observations on the limitations of TODOs, but I don't see any reason to be anti-

As far as I can gather, you've described TODOs being useless but harmless

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

#274

Post by shantly »

namirez wrote: post #15
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.

It's a great rule if you want to get people to never write down whatever information would have been contained in their TODOs. Anywhere, probably. Best case it remains but just without the TODO label, so... congratulations? Or goes in an issue tracker with all the other junk-issues that no one ever looks at.

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

#275

Post by tomlagier »

jandrewrogers wrote: post #265

The kind of software being written materially influences the semantics and use cases for TODO. I think much of the disagreement in this comment thread is based on a tacit assumption that everyone works on the same kinds of code bases. A web app is not the Linux kernel, and the priorities and concerns in development when annotating code will differ. For example, in much of the database code I work with, TODO is used f…

> You do not put these kinds of TODO items in an issue tracker because they are extremely local and contextual to the code they apply to. Filling the issue tracker with thousands of these kinds of issues which can't be understood without looking at the specific lines of code the comment was applied to has high overhead with negligible value.

This is one thing that really irks me about most code review cultures I've worked in - they can never stand to see a "naked" TODO (one without a reference to a tracking bug). You're spot on about the result.

The instinct to put a TODO is a note to self that there is a future cleanup, optimization, or improvement. It's a flag to readers of the code that the original author was not quite satisfied with some dimension of a solution. It is _not_ a work ticket, especially in the timeframe that most issue trackers work on (Maybe there needs to be alternate semantics for these "contextual TODOs", so that people do not immediately get the instinct to either put them in the queue or remove them.

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

#276

Post by badloginagain »

jwiley wrote: post #271

I used to be pro-TODO, I find myself today firmly in the no-TODO camp. I work daily on a large, mature code-base, littered with cryptic TODOs left by developers long-gone. They are generally as useful as street-signs in a ghost town. TODO: clean this up toDo: validate once ARF-211 is closed todo remove TODO factor TODO: lol, hae to enable in production for some reason TODO- will this scale? logarithmic? If I dive int…

I've seen this situation as well. A mature codebase where many of the original authors are gone, with many new devs still getting up to speed.

You run into the problem where these todos never get touched because you don't know which are the loadbearing hacks, and tumbling down the rabbit holes won't help you get up to speed.

The only real way to combat this is to dedicate a small team to just start ripping things out/upgrading things/etc.

The only way to clear a minefield is to blow up all the mines....

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

#277

Post by boudewijnrempt »

tomlagier wrote: post #275
jandrewrogers wrote: post #265

The kind of software being written materially influences the semantics and use cases for TODO. I think much of the disagreement in this comment thread is based on a tacit assumption that everyone works on the same kinds of code bases. A web app is not the Linux kernel, and the priorities and concerns in development when annotating code will differ. For example, in much of the database code I work with, TODO is used f…

> You do not put these kinds of TODO items in an issue tracker because they are extremely local and contextual to the code they apply to. Filling the issue tracker with thousands of these kinds of issues which can't be understood without looking at the specific lines of code the comment was applied to has high overhead with negligible value. This is one thing that really irks me about most code review cultures I've w…

Yes... My own codebase has 669 XXX's, 227 FIXME's and 1564 TODO's... For just 615,981 lines of code. And that's valuable information during development.

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

#278

Post by nitrogen »

drchickensalad wrote: post #237
makapuf wrote: post #232

Earlier quoted context omitted.

I prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.

Doesn't this still put all the commits on the main branch?

You can keep the branch commits for detailed history, and look only at merge commits the when you don't need details:

     git log --first-parent -m
This will show a linear history of merges, treating the merged code as being added in the merge commit. You can add -p to see the diffs.

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

#279

Post by nitrogen »

abricot wrote: post #258
makapuf wrote: post #240

Earlier quoted context omitted.

No you commit in feature branches then merge to main branch.

Do you then keep the branch around forever?

The branch history is preserved in the commit graph of the main branch, so you don't need to keep the feature branch.

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

#280

Post by arthurjj »

jandrewrogers wrote: post #265

The kind of software being written materially influences the semantics and use cases for TODO. I think much of the disagreement in this comment thread is based on a tacit assumption that everyone works on the same kinds of code bases. A web app is not the Linux kernel, and the priorities and concerns in development when annotating code will differ. For example, in much of the database code I work with, TODO is used f…

Recently at a social gathering of programmers TODOs came up and we all had dramatically different practices

Defense contractor: TODOs don't make it past CR. This is a heavily regulated industry with yearly release cycle

Embedded: TODOs can make it to nightly builds but not final/released build

Web: TODOs are fine, fix them as needed.

Post reply on HN