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

121–130 of 301 posts

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

#121

Post by james_s_tayler »

talaketu wrote: post #72
geofft wrote: post #43

Earlier quoted context omitted.

Your vision of the future should be in a bugtracker, not in code comments. TODOs give you a vision of what you would do if you had a few more hours. A bugtracker gives you a vision of what you would do if you had a few more years. (Where do you put "TODO: Learn tool X and rework all of this to be completely different using that tool if it makes sense" or even "TODO: The program crashes at shutdown with a double-free,…

I have completely the opposite opinion! Any bug in the bug tracker hanging around "in a few years" should* be closed. Comments should* persist while the source code issue to which they refer remains remarkable. *it's fun issuing such rulings.

It should just follow a retention policy. If no action on it in the last 12 months just automatically close it.

Otherwise issue tracker has thousands of items that the team will never realistically work on.

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

#122

Post by rumanator »

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…

> 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 repository such as source code sprinkled with TODO entries.

> 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 best way to fix the issue wasn't clear then."

That makes absolutely no sense at all, unless your goal is to simultaneously avoid accountability, poopoo other people's work, and actually do nothing to fix the problem.

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

#123

Post by james_s_tayler »

mlindner wrote: post #99

I don't understand the hatred for TODO statements (and similar), even if you never come back to them, they're still useful to know the future intention of the original author.

I agree but I also think that value is pretty marginal.

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

#124

Post by ygra »

dudus wrote: post #91
ddyevf635372 wrote: post #78

Earlier quoted context omitted.

Use IMPROVEME instead of FIXME ;)

TODO, FIXME and XXX are built into tools already. Sure you can make new stuff up but it makes it harder to find later.

Those things are configurable, though, so new markers are rarely problematic from a tooling perspective. Getting your teammates to agree on using the same markers is perhaps the bigger problem.

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

#125

Post by TeMPOraL »

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 this to be a part of cleanup after a main task - I go over all the TODOs in the area I worked in, and implement the simple ones, delete the stale ones, move the serious ones into issue tracker, and leave the rest for future reference.

All of this applies also to FIXME, HACK and NOTE comments - three other types I use. Out of these, NOTE are informative, "seriously please pay attention" comments.

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

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

#126

Post by rumanator »

StuffedParrot wrote: post #92
Forge36 wrote: post #59

Earlier quoted context omitted.

When the file is next edited by the next individual. They don't need to be tracked

Sure, and then you end up with linux.

> Sure, and then you end up with linux.

You mean the most successful software project in the history of mankind?

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

#127

Post by TeMPOraL »

somehnguy wrote: post #85
kanox wrote: post #61

Earlier quoted context omitted.

> This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization. I assign the same meaning to TODO or FIXME markers but a lot of people see this is as a measure of poor quality so instead I write regular comments of the form "this could be made better by doing X and Y".

That may work but I find those comments tend to get lost over time. TODO/XXX/FIXME support are built into IntelliJ which makes stuff like that super easy to find. If some random dev looks and decides its low quality because of those words...well I don't care because its a silly metric to judge on.

And even if they aren't supported by default in your IDE/editor, they're perfect hooks for recursive grep. A simple

  grep -rn TODO *
and you see a nice list of all of them, with files and lines.

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

#128

Post by cgag »

sombremesa wrote: post #23
BurningFrog wrote: post #20

Earlier quoted context omitted.

To me, FIX implies that something is wrong, not that it works but could use improvement. I would like to have a tag for "here's something that works, but could be improved" though!

Pray tell, what line would you NOT put that tag on? That's like, all code...

Something I've seen Jonathan Blow do that I like is tag things // @Speed when doing a quick to type but slow to run kind of first pass.

It seems nice to have tags for places to jump where the improvements are obvious, rather than hoping to just remember/spot them later.

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

#129

Post by rumanator »

Forge36 wrote: post #59
StuffedParrot wrote: post #49

Earlier quoted context omitted.

Sure, for the individual. Does the project track them internally? How are they followed up on? How is work assigned and prioritized?

When the file is next edited by the next individual. They don't need to be tracked

> When the file is next edited by the next individual.

That usually means you add a separate goal and focus to your ticket to be committed inan unrelated issue, which in some projects is frowned upon as it avoids tracking, context, or auditing.

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

#130

Post by TeMPOraL »

sedatk wrote: post #118
berkut wrote: post #45

Earlier quoted context omitted.

So that it's grep-able?

Why would you grep in a scenario where a note is written because "[the]... code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization.". It's exactly meant for when you encounter it, it's not meant to be found externally.

Because it's trivial to add special highlighting to such notes in most editors and IDEs. Hell, a lot of them come with a configurable list of these comment keywords already built in.
Post reply on HN