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

251–260 of 301 posts

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

#251

Post by regularfry »

TeMPOraL wrote: post #134
rumanator wrote: post #122

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

From the point of view of being in the middle of working with some piece of code, it's the issue tracker that's out-of-band! Also, a lot of those TODO entries tend to not be good entries into issue tracker (do you want to track "add extra error checks foobar at line 213 in quux.c"), and they tend to be very localized to the area of code they're left in - which means that, unless your issue tracker supports some way o…

The counter-argument would be that if it's work, and it needs to be scheduled (which is what we're talking about here) then it needs to be tracked wherever all the rest of the work is, so that it can be made visible and prioritised alongside everything else.

The "how do I encode a link to code that doesn't go stale" solution is to use a link to the source code repo browser which points to a specific time and place - don't point at `master`, point at the specific revision hash you're talking about.

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

#252

Post by efnx »

This is why I wrote https://srcoftruth.com - it will find your todos and open, track and eventually close a ticket for each distinct todo in your repo. Works on GitHub repos and issues (private and public). Currently building JIRA integration and generic web hooks. And it’s free!

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

#253

Post by peterwwillis »

A lot of people suggesting "TODOs should become tickets before accepting the code for merge". So... How do you do that? Manually, I assume?

A while ago I started on a tool to automate managing GitHub Issues, but the libraries and tools around issues were mostly crap, so I stopped. But I'd love to get a generic tool together to manage issues using single lines in a text file (such as code comments, or Markdown lists), such that editing a line in the file causes the tool to create, update, close, or delete issues. Infrastructure as Code, but for issues/tickets.

You could then script pre-commit or pre-merge hooks to create issues for TODOs on the fly, and later on have a job skim though code and delete TODO comments whose issues had been closed. Extend it to use Jira and you can use it at work, too.

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

#254

Post by vl »

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…

In recent years at Google a rule was adopted that TODO should be followed by a bug number or not be put in at all.

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

#255

Post by derefr »

TeMPOraL wrote: post #125
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…

It's critical for me too, for exactly the reasons you listed. RE point 2., it also applies to issue trackers and other "proper" way of encoding TODOs - if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Context switch is deadly here. RE point 5., I try to work through them as I go. I consider t…

> RE point 2., it also applies to issue trackers and other "proper" way of encoding TODOs - if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Context switch is deadly here.

It sounds like the ideal thing to do here, in order to stay in flow, is for these notes to be inline TODOs while coding, but for them to somehow get turned into issues before anyone else sees them. I.e. by a pre-commit hook, or by whatever tooling you use to squash commits when building PRs/patches. If you write them in a standardized format, something should be able to parse them out.

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

#256

Post by fierarul »

johndoe18637 wrote: post #185
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…

At work we made it a policy to allow TODOs to remain until code review. At least there, with the help of a second pair of eyes, they should be resolved, removed or made into an issue. Until now this approach works quite well for us.

This is a good approach except it breaks the link from the TODO location to the issue. Are you replacing the TODOs with an URL for the issue or something like that? How do you know a file has issues/todos by just looking at the file in your editor/IDE?

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

#257

Post by TeMPOraL »

regularfry wrote: post #251
TeMPOraL wrote: post #134

Earlier quoted context omitted.

From the point of view of being in the middle of working with some piece of code, it's the issue tracker that's out-of-band! Also, a lot of those TODO entries tend to not be good entries into issue tracker (do you want to track "add extra error checks foobar at line 213 in quux.c"), and they tend to be very localized to the area of code they're left in - which means that, unless your issue tracker supports some way o…

The counter-argument would be that if it's work , and it needs to be scheduled (which is what we're talking about here) then it needs to be tracked wherever all the rest of the work is, so that it can be made visible and prioritised alongside everything else. The "how do I encode a link to code that doesn't go stale" solution is to use a link to the source code repo browser which points to a specific time and place -…

Linking to revision doesn't help in the context of our discussion - it still doesn't solve the problem of automatically getting that information inline with the code at the correct place in the file, for the correct time (if it would show up only in the linked revision then it would be useless; if it would be inherited by future revisions, then how do you delete the annotation once it isn't needed anymore?).

As for tracking work, these kind of comment notes are about units of work small enough that tracking them would be very counterproductive for the company. This would be extreme level of micromanagement.

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

#258

Post by abricot »

makapuf wrote: post #240
drchickensalad wrote: post #237

Earlier quoted context omitted.

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

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

Do you then keep the branch around forever?

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

#259

Post by TeMPOraL »

derefr wrote: post #255
TeMPOraL wrote: post #125

Earlier quoted context omitted.

It's critical for me too, for exactly the reasons you listed. RE point 2., it also applies to issue trackers and other "proper" way of encoding TODOs - if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Context switch is deadly here. RE point 5., I try to work through them as I go. I consider t…

> RE point 2., it also applies to issue trackers and other "proper" way of encoding TODOs - if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Context switch is deadly here. It sounds like the ideal thing to do here, in order to stay in flow, is for these notes to be inline TODOs while coding ,…

Yes, and it's entirely doable. In case of my own Org Mode notes, I could probably hack together something that does that pretty quickly in both directions (move the note from source file to Org Mode, and display notes from Org Mode inline in the code, at appropriate places). A small alteration could make this work with an issue tracker API.

But that would still be very fragile. I don't think there's a good way to record spatio-temporal coordinates of a piece of a file in a way that's resistant to changes. The usual way is to record file position + preceding and following context, but that'll break whenever someone does some bigger changes immediately around the note you're tracking. Perhaps there is some good trick to solve this, but you have to ask yourself - why go to all this ridiculous amounts of trouble to avoid putting TODO notes in comments? It's not like most of them would fit well in an issue tracker either - they tend to be too small or too context-specific to form a nicely packaged unit of work, and making this level of detail visible to managers is just tempting them to cause a disaster for the company.

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

#260

Post by TeMPOraL »

yoz-y wrote: post #229
TeMPOraL wrote: post #125

Earlier quoted context omitted.

It's critical for me too, for exactly the reasons you listed. RE point 2., it also applies to issue trackers and other "proper" way of encoding TODOs - if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Context switch is deadly here. RE point 5., I try to work through them as I go. I consider t…

> if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Why not both? You can refactor todos with a ticket number before you commit the code. So the TODO can have some more context associated with it and maybe a discussion.

I might do that after I'm done with the code and about to commit it, but in my experience, there's very little overlap between the kinds of things you'd want to track on your company's issue trackers and the things you want to just jot down inline with the code. The latter tend to be too small.
Post reply on HN