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

141–150 of 301 posts

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

#141

Post by psalz »

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 on a new project (which might just be a new module in an existing code base) my mind tends to bombard me with these hypotheticals, so it is tremendously relaxing to just whip up a quick note and know that it will be dealt with by future me :).

To actually enforce this, for the past couple of years I've been using NOCOMMIT comments, together with a git hook that actually prevents me from committing those lines. I rely on this workflow so much now that I can't even imagine going back. I also get really nervous in pair-programming scenarios when someone will say "Yeah, I'll change/fix/adjust that later" - all I'm thinking is "but will you remember?!".

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

#142

Post by hutzlibu »

rurban wrote: post #120
mewse wrote: post #100

Earlier quoted context omitted.

The lead programmer at my very first coding job taught me to put a string of at least three hash marks in a comment, to denote “this is a thing which is okay during development but absolutely must be changed/fixed before shipping this product”. The more essential the change/fix, the more hashes. Made it really easy to do a global search for them, and you could easily filter the results to only show the most important…

This should be marked as FIXME, not some management savy ###

Why?

I also use ###. It is just a different style.

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

#143

Post by mytailorisrich »

alkonaut wrote: post #139
mytailorisrich wrote: post #131

Earlier quoted context omitted.

> “this is a thing which is okay during development but absolutely must be changed/fixed before shipping this product”. These should not reach the master codebase and should thus be fixed before you merge your code into it.

I think if multiple people are working on a code base which will not ship for years, then having those can be acceptable. Obviously if “next release” is a deploy from master in 2 weeks then it isn’t.

It does not make it acceptable, quite the opposite as there would actually be less time pressure to ship code. What you describe would lead to an accumulation of issues over time that will degrade the codebase until it ships and then makes maintenance a nightmare.

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

#144

Post by Jach »

shhsshs wrote: post #113
Jach wrote: post #107

Earlier quoted context omitted.

At my work we just file a bug and make sure it gets prioritized as a must-fix... The code might contain a bug number and remark too for redundancy, but the bug itself generally spells out the bits of code that need to be changed/removed/whatever. Using code comments really seems like the wrong place to prioritize changes. Even on personal projects.

I agree in principal, though if the intent is to have the minimal amount of side-tracking while marking something as TODO for the future, I don’t think you can get better than a comment. A nice cli interface for creating tickets in GitHub/Jira/etc. would help with that. I wonder, would it be nice to have a pre-commit hook that scans for TODO comments, removes them, and drafts tickets? Then both flows would work well.

I suppose it depends on how far you trust your ability to keep everything in your head, and reload everything coming back, and follow through on notes to self. I make todos too, but I try to honor a self-agreement that they be short lived and ideally not make it very far beyond my machine.

I linked https://github.com/dspinellis/git-issue in another comment but it gives a sense of the command line experience. I've also at times hacked up various scripts to create or modify items in github/jira/our internal POS, it can make things more likely to hit the tracker than to be met with a shrug. (It's so odd how sensitive programmers can be to even minor blocks in flow like a few seconds waiting for a webpage, or avoiding refactoring a method / class because in Java a new method might best belong to a new class which to do things 'proper' often entails a new file and then another new file for unit tests, adding them to version control, and all that takes like 30 seconds even with IDE support and is annoying.) I've at times thought about a small vim command that would call one of those scripts to create a new issue pre-templated with the file and location I was on, create, then insert the work item id, but never got around to it. As a pre-commit hook something to look for TODOs explicitly might be interesting, though I generally dislike hooks.

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

#145

Post by wutbrodo »

sedatk wrote: post #53
wutbrodo wrote: post #35

Earlier quoted context omitted.

What's the advantage of throwing away context that could be useful in the future? I've taken ownership of codebases with technical debt before, and when modifying the code for something time-sensitive, I often annotate issues with the code whose solutions (usually refactoring) can't be fit into the timeline of the current project. I (or others) can then take advantage of these annotations when I have time to dedicate…

You don't throw it away, you put it in the issue tracker where it can be prioritized, tracked and categorized. If it's not worth of the issue tracker, it shouldn't be worth of a TODO either.

I don't see why you'd hobble yourself by removing a method of tracking todos, in favor of one that's higher-overhead and more dangerous (much higher chance of getting out of date due to implicit coupling).

> If it's not worth of the issue tracker, it shouldn't be worth of a TODO either.

This is what I mean by throwing away work. If you have some insight about the code, your requirement that the insight be thrown away until you can "prioritize, track, and categorize it" makes no sense. Allowing a lighter-weight annotation that lives with the code that it describes allows much more flexibility: it's descriptive of the code and agnostic to its eventual fit into your tasking, as you can integrate it into formally tracked tasks or lump it in with related changes. Blanket bureaucratic rules for bureaucracy's sake is pointless, and I say that as someone who's a very strong believer in ticket tracking hygiene.

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

#147

Post by bryanrasmussen »

From my time as a consultant I started doing some TODOs with a view to when I would be off of the project, for example there was code in a place that I knew would be not necessary due to changes at a certain time in the future I would put in a TODO because there was a chance I wouldn't be there when that code needed to be removed or changed. Who knows if anyone ever heeded them though.

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

#148

Post by cthalupa »

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…

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

If I'm on another team looking at using your code for whatever reason, I may not be familiar with your ticketing system, what is where, how it's organized and prioritized, etc. I appreciate an indication in the code that that function or class might have some significant areas for improvement. If it's relevant enough to what I'm doing, maybe I'll handle the TODO and open up a code review for your team. Ideally you've got a TODO with some details and also a ticket I can reference to see what's going on with it or what discussion has already occurred around it.

But companies of FAANG size often have so many different developers on totally different teams that they're probably not going to have the time or inclination to go look through your ticket backlog. Having any deficiencies or areas for improvement clearly marked in the code is a benefit in those situations.

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

#150

Post by jordanbeiber »

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 makes a lot of sense if you are only a few people working the code. If not, maybe spend some minutes at the end of the day to register them as issues?

If that’s to cumbersome or difficult, something is wrong in the process or tooling, IMHO.

It makes me go crazy when I find todo scattered everywhere - often these todos are short, hard to decipher and ownership and priorities become jumbled.

What you describe in the points above actually looks like an issue tracker to me.

When I find todos I tend to cut them and paste them as issues trough slack bot integration. It keeps an ok flow, although I get annoyed that my fellows could not be bothered...

To each their own I guess, and whatever works!

Edit: I love in-line comments and documentation though. Just not todos. :)

Post reply on HN