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

191–200 of 301 posts

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

#191

Post by iforgotpassword »

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…

Ticket systems are great and I use them for pretty much everything I do, and places like github make it very easy to use them even for your small hobby projects.

However I still think it's valuable to add TODO and the likes to your code, especially when working on open source, since the issue tracker might not be around forever, you switch platforms, project gets forked, some part reused in another project. It also makes it much easier to get into a new code base, just like comments in general.

Even at work we do this even though using tickets for everything is mandatory. I like it. And in case we open source some stuff folks won't have access to our internal ticket system obviously, so having something more than "see #4642" in your code is good.

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

#192

Post by yitchelle »

ben174 wrote: post #161
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…

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.

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

#193

Post by stestagg »

marvin wrote: post #180
daemin wrote: post #160

Earlier quoted context omitted.

You can rewrite the git history when you squash commits for example. One case I've heard is that some people no longer have their names on git commits they made to various Google open source projects because their commit went inside, where it was rebased, merged, integrated, squashed, and then what the public sees is a single git commit by a Google insider that is the result of thousands of individual commits.

This is a beautiful example of the general case «why don’t you just use X tool that was designed for this?» but can’t because someone made a decision that makes X tool unusable.

Workflows are full of trade offs. Different people & teams value different features in different ways. It’s what makes software development such a vibrant ecosystem.

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

#194

Post by smcl »

sullyj3 wrote: post #169
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…

This completely negates the cost of context switching. Not all of us are superhuman multitaskers.

I don't think anyone's saying that any time you encounter something which needs fixing you should drop your current work, open up the ticketing system and type out a detailed description there. It's just that the TODO comments shouldn't be part of your final commit (or equivalent).

Think of it like those little `print(f"foo is {foo}")` statements you add or the code you comment out while debugging - you use them to quickly develop piece of functionality, then you back them out before `git commit`. This is the point where you'd collect them together and create the tickets - your local work is "done" and you're doing a final review.

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

#195

Post by cjfd »

The 'many from over a decade ago' part shows one problem with TODO comments. Very often these TODOs are never done. Really, TODO comments should not exist. When you are writing some code is the point when you know most about it and is therefore also the best point to write code of optimal quality. Also, for some TODOs I encounter in the wild I cannot really shake the impression that the author is showing off by suggesting something that sounds smart but actually is impractical and should never been done.

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

#196

Post by simias »

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.

Or simply the features are never needed so they are never implemented. There's rarely a perfect match between the hardware capabilities and the OS interface, that's the cost of the abstraction. Sometimes there's no trivial way to expose the feature or it would require too much work for something that's not deemed necessary.

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

#197

Post by sergiosgc »

daemin wrote: post #160
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

You can rewrite the git history when you squash commits for example. One case I've heard is that some people no longer have their names on git commits they made to various Google open source projects because their commit went inside, where it was rebased, merged, integrated, squashed, and then what the public sees is a single git commit by a Google insider that is the result of thousands of individual commits.

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

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

#198

Post by panpanna »

TODO: do something about all those TODOs in our codebase.

This could make an excellent XKCD.

Edit: to turn this into a more useful comment, let me add that TODO is an important component of test-driven development. If you read Kent's original example with Fibonacci you will note that he splits the functionality into multiple small milestones.But unlikes traditional waterfall these appear organically as TODOs in the test and implementation code as things progress.

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

#199

Post by TheYumasi »

ben174 wrote: post #161
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…

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.

I have something similar in Emacs with magit-todos, although it's very slow on large codebases.

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

#200

Post by jbjorge »

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. So in other words - one issue tracker.

I can't quite understand why people would want to have multiple places to list code issues.

Post reply on HN