The Linux codebase has over 3k TODO comments, many from over a decade ago • Hacker News Board

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

#231

Post by boomlinde » Mon, Dec 30, 2019, 2:18 PM UTC

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…

There is alway conceptual TODO at a given stage of development, whether you spell it out or not. If you develop "depth first", these are few and mostly transient, and there is no real benefit to spelling them out. You work through the details before continuing. If you instead program "breadth first" you will ignore many details for the time being and instead queue them up for a future look, and tools like post-its, TODO comments, task management tools become really helpful.

My main gripe with TODO is that they're comments. Comments don't age well. Sometimes they're not written well. I'm sure that a lot of the 3000 TODOs in the Linux kernel are either things that are already done or things that are no longer considered goals. Some of them are surely hard to figure out by now. Personally I only commit a TODO comment in some limited circumstances. Most of the time I make sure that there are not TODO left before I commit. The ones that may be left at the time I want to commit are great candidates for tasks on an agile board or new user stories.

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

#232

Post by makapuf » Mon, Dec 30, 2019, 2:24 PM UTC

azinman2 wrote: post #205

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.

Because it becomes more compact. Most of the time git commits are things that don’t make sense to have at a more macro level. Squashing into a single commit that represents a coherent improvement, particularly for large projects, is the best way to read its history.

I prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.

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

#233

Post by Psyladine » Mon, Dec 30, 2019, 2:25 PM UTC

jcims wrote: post #10

Only ~3,000? Not really that surprising, is it? I think a more interesting metric is how many TODOs have been resolved/removed in that time. I have no interest in figuring out how to figure that out though, so...

Couldn't you take an older kernel and do a comparison of the TODOs in the most recent, and get a count like that?

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

#234

Post by arcticbull » Mon, Dec 30, 2019, 2:27 PM UTC

yoz-y wrote: post #230

SlowRobotAhead wrote: post #223

Earlier quoted context omitted.

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

Exactly by all means have them in your working branches but track them before they hit master

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

#235

Post by mcv » Mon, Dec 30, 2019, 2:29 PM UTC

boomlinde wrote: post #231

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…

There is alway conceptual TODO at a given stage of development, whether you spell it out or not. If you develop "depth first", these are few and mostly transient, and there is no real benefit to spelling them out. You work through the details before continuing. If you instead program "breadth first" you will ignore many details for the time being and instead queue them up for a future look, and tools like post-its, T…

Ideally, every TODO should quickly result in an item on your issue tracking system. The item should point to the TODO in the code so it's easily found. That makes it easy to clean it up once it's not necessary anymore.

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

#236

Post by fennecfoxen » Mon, Dec 30, 2019, 2:29 PM UTC

boomlinde wrote: post #231

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…

There is alway conceptual TODO at a given stage of development, whether you spell it out or not. If you develop "depth first", these are few and mostly transient, and there is no real benefit to spelling them out. You work through the details before continuing. If you instead program "breadth first" you will ignore many details for the time being and instead queue them up for a future look, and tools like post-its, T…

In routine application development (which, to be fair, is a slightly different problem than a kernel,) TODO comments are probably at their best when identifying code deficiencies that you don't actually have plans to fix, pointing out refactoring opportunities, and documenting other hacks. If you put this sort of a thing in a bug tracker or other system, no one will see it when they browse the code.

(On the other hand, the bug tracking system is definitely the place to put things which should actually get done.)

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

#237

Post by drchickensalad » Mon, Dec 30, 2019, 2:31 PM UTC

makapuf wrote: post #232

azinman2 wrote: post #205

Earlier quoted context omitted.

Because it becomes more compact. Most of the time git commits are things that don’t make sense to have at a more macro level. Squashing into a single commit that represents a coherent improvement, particularly for large projects, is the best way to read its history.

I prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.

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

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

#238

Post by jedisct1 » Mon, Dec 30, 2019, 2:33 PM UTC

I've never seen "TODO" / "FIXME" sections ever being eventually done/fixed. Never.

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

#239

Post by speleding » Mon, Dec 30, 2019, 2:34 PM UTC

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…

I think it makes sense to refine the levels a bit more. We use FIXME, TODO and OPTIMIZE in order of decreasing importance.

- FIXME should really not even be committed, except in a proof of concept

- TODO should be fixed eventually, preferably before release to production

- OPTIMIZE is a "nice to have" that gets fixed on a quiet day

Furthermore, TBD (to be done) indicates where new expected functionality is expected to appear, deliberately different from TODO because the JetBrains editor flags TODO / FIXME for confirmation before commit, and will ignore TBD.

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

#240

Post by makapuf » Mon, Dec 30, 2019, 2:37 PM UTC

drchickensalad wrote: post #237

makapuf wrote: post #232

Earlier quoted context omitted.

I prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.

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

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