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

221–230 of 301 posts

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

#221

Post by simias »

TeMPOraL wrote: post #159
jcelerier wrote: post #153

Earlier quoted context omitted.

> I date them all. I have a Yasnippet for all the above, which expands "todo" into "TODO: $ -- My Name, 2019-12-30", $ being where the caret stops after expansion. Same for "fixme", "hack" and "note". why is that necessary ? git blame gives it to you already

Because running git blame on code breaks the flow. Because git blame may give you wrong author and date (say someone edited the code around the note, changing its indentation level; EDIT: or rebased it, as 'daemin says). Because git blame is not a grep-friendly solution. Because code sometimes lives longer than version control systems (I've worked with codebases older than git). Because very often code lives longer t…

I agree with all your other points but I want to point out that if `git blame` breaks your flow I recommend that you look up how to better integrate git with your code editor, it's a huge time saver IMO. With vim-fugitive I can just ":Gblame" on any code I'm currently browsing and immediately I get a side-pane with the annotations for every line. ":Gdiffsplit" shows me the diff between my version and HEAD etc...

But beyond that I agree completely, `git blame` is not the right way to track the authorship of annotations in a file.

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

#222

Post by MiracleUser »

arcticbull wrote: post #218
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.

I wonder if there are any tools to create tickets from TODO's

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

#223

Post by SlowRobotAhead »

arcticbull wrote: post #218
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.

I think you are ignoring all OP’s points about short term memory and not getting side tracked on optimizations. The latter of which gets me all the time.

So you would recommend instead of moving a long he drops what he’s doing and go link the ticket number back into code just to leave a TODO that in high likelihood is him working on eventually or not anyhow? Weird flow but ok.

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

#224

Post by Xophmeister »

MiracleUser wrote: post #222
arcticbull wrote: post #218

Earlier quoted context omitted.

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.

I wonder if there are any tools to create tickets from TODO's

I used to have a pre-push hook, I think, that would cancel the push if there were any TODOs or FIXMEs in the codebase, displaying them out nicely, with their location. I ultimately turned it off :P

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

#225

Post by jpswade »

agumonkey wrote: post #204
jpswade wrote: post #178

Earlier quoted context omitted.

A todo is fine, only if there’s a way to get it to done. There must be a plan otherwise it’s a pointless comment.

How would you call a comment for a potential idea/feature ?

The code isn’t the right forum for feature suggestions and ideas.

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

#226

Post by jmiserez »

psalz wrote: post #141
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…

Great points, especially 1 - 3. For me it is also often not so much about optimizations, but rather additional use/edge cases that might need consideration, but I'm not sure yet because I haven't e.g. fully fleshed out an interface yet. Often times I will ultimately just delete the note (going back to your third point), but other times it might result in an additional test case, for example. Whenever I'm starting out…

Yes, automatic enforcement is invaluable. Instead of a commit hook you can also use a pre-receive hook on the server. This allows rebasing, wip commits etc. locally and doesn't require any client config.

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

#227

Post by pm215 »

booleanbetrayal wrote: post #26
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.…

Without auditing, driver code makes sense to me. Guessing there is a lot of vendor churn and therefore a lot of caveats to keep track of ... right up until the point the driver is obsolete and put on life support, never be looked at again.

Also driver and other hardware-specific code is more likely to have a smaller population of developers to tend and improve it, and a smaller population of users to care about getting it fixed, so minor issues will linger longer. (I had a look at the 'arm' ones, and many of those are in code specific to a particular board or other piece of hardware.)

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

#228

Post by ilammy »

spockz wrote: post #209
sergiosgc wrote: post #197

Earlier quoted context omitted.

I don't understand the need to rewrite history. This is a good example against that practice.

At least these days co-authorship can be recorded in the commits.

That’s just conflating GitHub support of these tags with git. Similar "Signed-off-by" tags are in use by Linux kernel pretty much since forever.

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

#229

Post by yoz-y »

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…

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

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

#230

Post by yoz-y »

SlowRobotAhead wrote: post #223
arcticbull wrote: post #218

Earlier quoted context omitted.

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.

I think you are ignoring all OP’s points about short term memory and not getting side tracked on optimizations. The latter of which gets me all the time. So you would recommend instead of moving a long he drops what he’s doing and go link the ticket number back into code just to leave a TODO that in high likelihood is him working on eventually or not anyhow? Weird flow but ok.

Just do it after you finish and before you send your code for review. Just don’t merge dangling TODOs
Post reply on HN