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

201–210 of 301 posts

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

#201

Post by alpaca128 »

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.

Why would you intentionally leave out a TODO tag to make it harder to find?

Lowering the barrier to see such comments increases the chances of people actually handling them. Having a highlighted TODO in the code makes it much more visible even if you don't use grep.

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

#202

Post by panpanna »

If you think that is horrible, let me tell you a story about the opposite approach:

There is very successful company, let's call them "LEG", that makes computer thingies. In order to improve customer confidence, "LEG" has adopted a very strict release policy: all instances of TODO, FIXME, BUG and ERROR are removed before a release.

If you have a variable called "error", automated tools will flag it and you will have to explain to your boss why you could not have used any other name.

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

#204

Post by agumonkey »

jpswade wrote: post #178
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…

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 ?

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

#205

Post by azinman2 »

sergiosgc wrote: post #197
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.

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.

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

#206

Post by sweden »

panpanna wrote: post #202

If you think that is horrible, let me tell you a story about the opposite approach: There is very successful company, let's call them "LEG", that makes computer thingies. In order to improve customer confidence, "LEG" has adopted a very strict release policy: all instances of TODO, FIXME, BUG and ERROR are removed before a release. If you have a variable called "error", automated tools will flag it and you will have…

Which makes sense. Why are you making a customer release with outstanding TODOs/FIXMEs/BUGs/Whatever in the code? Are there things left to do? Are you delivering something incomplete to the customer while saying it's bug free and feature complete?

You need to make a decision whether to actually fix what you intended to fix or to judge that it's not relevant anymore.

The script is letting you know that there are outstanding things in the code that might have been forgotten. If you are the owner of those TODOs and choose to just delete the comment in order not to have any extra work, then maybe someone in your company should review your presence there.

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

#207

Post by panpanna »

sweden wrote: post #206
panpanna wrote: post #202

If you think that is horrible, let me tell you a story about the opposite approach: There is very successful company, let's call them "LEG", that makes computer thingies. In order to improve customer confidence, "LEG" has adopted a very strict release policy: all instances of TODO, FIXME, BUG and ERROR are removed before a release. If you have a variable called "error", automated tools will flag it and you will have…

Which makes sense. Why are you making a customer release with outstanding TODOs/FIXMEs/BUGs/Whatever in the code? Are there things left to do? Are you delivering something incomplete to the customer while saying it's bug free and feature complete? You need to make a decision whether to actually fix what you intended to fix or to judge that it's not relevant anymore. The script is letting you know that there are outst…

Let me clarify: they are not fixing the issues, just hiding them from customers.

Are these important issues that should have been fixed or just small good-to-have things? The answer is: yes

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

#208

Post by spockz »

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…

Fully agree on the workflow impact. What I usually do is:

1. Write the synopsis of the todo in the code 2. On creation of the MR/PR start discussions on each todo. 3. For each todo which has no quick fix or obvious solution a new issue is created referring to the todo.

This way I get to stay in the flow and record it in a big tracker for further discussion.

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

#209

Post by spockz »

sergiosgc wrote: post #197
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.

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.
Post reply on HN