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

211–220 of 301 posts

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

#211

Post by kjeetgill »

jbjorge wrote: post #200

If you don't use an issue tracker, then to-dos is your issue tracker. If you're using an issue tracker as well as to-dos in the code, then you've got two issue trackers. If you're using an issue tracker that also reads to-dos in the code, then you've got one issue tracker. Where I work we don't have an integration between the tracker and our code, so we disallow to-dos, but allow comments with references to issues. S…

In practice they work quite differently in a number of ways, depending on your workflows. I'll outline mine, but from this thread you can probably tell, it's not unique.

Jira/Github-like issue trackers can often become blackholes for certain kinda of work. Not all TODO's NEED to get done, they're often just reminders to revisit decisions with the full context of the code. The two most common cases that come to mind are deferred possible optimizations and deferred generalization.

In my workflow, it's more of a counterbalance against premature optimization, abstraction, and distraction. It also has the benefit of:

a) informing reviewers what wasn't done and why right in the diff. It can often spark good conversations of if it's worth scoping them in or maybe scheduling in (Jira!) soon.

b) Allowing people to revisit the above when the next engineer is changing things in the neighborhood.

In my experience, if and engineering side ask isn't addressed in a month or 2 it quickly turns into one ticket that sits in the backlog forever and maybe another that get's created when the "idea" get's floated again.

Naturally, your milage may vary.

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

#212

Post by fian »

yitchelle wrote: post #192
ben174 wrote: post #161

Earlier quoted context omitted.

Back in my Microsoft development days, I fondly remember Visual Studio automatically adding todo comments to a dedicated little docked window in the corner of the IDE. It was very efficient and would always be in the corner of my eye and I would always circle back to them as a result.

It was a while ago since I used Eclipse, but I think it greps all the TODOs in the source code or project workspace, and list them as a list of TODOs :-) for you to work through. Not sure if it still does this but I found it to be a really good feature.

Eclipse still has this and even better you can define your own tags that are also added to the list view. You can then filter by tag name in the list view.

I found this handy when doing large refactorings (e.g. that took multiple weeks or months). I could define a custom TODO for that refactoring for labeling tasks that I knew I would need to resolve before completing the refactor but was not able to tackle immediately. It made it less stressful knowing I would be easily able to find the tasks again and the central list made it efficient to clear them all.

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

#214

Post by foobarian »

stinos wrote: post #156
jonny383 wrote: post #104

TODO is vital for my development process. Sure, maybe there's better programmers who don't use or need TODO, but for me, it's a critical method for the following reasons. 1. It prevents my "flow" from being sidetracked by micro-optimizations that are probably too early to consider necessary anyway. 2. It helps me to retain my short term memory on the code I am working on. If I branched out at each TODO to implement s…

Your points are valid, and I've used it as well many times, but ther's always the risk you find yourself in a situation where there's just a growing number of TODO items. Which isn't (always) a problem per se, but severely limits there usefulness and could be a sign of ever-expanding problems all over the code base. Worst I've seen is REALLYTODO popping up, then you know the ship is probably beyond sinking. Then agai…

One of the more entertaining activities at work is to make fun of ancient TODO comments in our giant codebase. There are some all-stars most of us know by heart such that they made it into the internal company jargon. Tl;dr we ask to resolve TODOs during code review and don't allow them in now.

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

#215

Post by gumulka »

shhsshs wrote: post #113
Jach wrote: post #107

Earlier quoted context omitted.

At my work we just file a bug and make sure it gets prioritized as a must-fix... The code might contain a bug number and remark too for redundancy, but the bug itself generally spells out the bits of code that need to be changed/removed/whatever. Using code comments really seems like the wrong place to prioritize changes. Even on personal projects.

I agree in principal, though if the intent is to have the minimal amount of side-tracking while marking something as TODO for the future, I don’t think you can get better than a comment. A nice cli interface for creating tickets in GitHub/Jira/etc. would help with that. I wonder, would it be nice to have a pre-commit hook that scans for TODO comments, removes them, and drafts tickets? Then both flows would work well.

I have somethink like this in the pre-commit script: https://pastebin.com/XmMHTvZR

It works only for gitlab and assumes that the remote is named origin.

This will create an issue with the title text being everything after TODO. It does not support multiline and only looks at the newly added lines, but does not remove from the commit or alters them.

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

#216

Post by harryf »

slimsag wrote: post #11

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

Herbert XU is apparently still in hiding after receiving threats of a good kicking ... https://sourcegraph.com/github.com/torvalds/linux@fd6988496e...

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

#217

Post by bythckr »

3k TODOs in a vital opensource project. Why? Lack of funding or lack of coders or Linus/Stallman(FSF/GNU, who has resigned but is he replaced?) is unable to be everywhere and he need a bigger team to support him? What is the "news" here? Is it a warning to avoid Linux's possible "Heartbleed" type issue?

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

#218

Post by arcticbull »

jonny383 wrote: post #104

TODO is vital for my development process. Sure, maybe there's better programmers who don't use or need TODO, but for me, it's a critical method for the following reasons. 1. It prevents my "flow" from being sidetracked by micro-optimizations that are probably too early to consider necessary anyway. 2. It helps me to retain my short term memory on the code I am working on. If I branched out at each TODO to implement s…

TODOs are fine but only if you also have associated cross linked tickets in your bug tracker. You shouldn’t ever commit TODOs in your code without a ticket number or exactly this will happen.

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

#219

Post by kortex »

yongjik wrote: post #38
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…

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…

Exactly.

TODOs should be an adjunct to the issue tracker. An issue could be "Clean up/resolve all TODOs in module qux". but each of those comments on there own are rarely worth the issue on their own.

Also not every project has the FTEs or the scope to hit every TODO in the first pass. Maybe it's all a glorified demo and these are "Road closed" points to be enhanced/hooked in to in the future.

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

#220

Post by sethammons »

I'll litter my code with TODOs while developing, especially in a green project. However, our team has a practice that we find valuable: any TODO checked into the master branch must contain a link to a jira ticket. A TODO that can't be prioritized is likely to never get done. We like the forcing-feature of making the choice to handle it now, or working to get it prioritized.
Post reply on HN