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

161–170 of 301 posts

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

#161

Post by ben174 »

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.

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

#162

Post by kanox »

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.

> those comments tend to get lost over time

That's fine, they don't need to be tracked. There are other systems for issues that need tracking.

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

#163

Post by keyP »

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 still use this feature, it comes under the "Task List" window. Adds any "TODO" comments in realtime by default but it's also possible to extend what tokens show up alongside "TODO" [0]. I've added "Hack" or "Perf" for temporary implementations that definitely can be improved but not necessarily critical.

[0] https://keyboardp.com/post/40190774577/using-task-list-token...

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

#164

Post by coldtea »

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

Neither FIXME nor ### are "standards" so the distinction is moot. Can use either...

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

#165

Post by ilammy »

jcelerier wrote: post #153
TeMPOraL wrote: post #125

Earlier quoted context omitted.

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

There are many contexts where blame info is not visible by default: dumb editors, code review browsers, search results, etc. It's a low-effort signaling about the age of TODO as well as whether the person who left it is still around.

It's a similar reason for why you sometimes leave implementation comments in the code, not in git commit messages.

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

#166

Post by hvdijk »

john_moscow wrote: post #32

I use this pattern across my codebase for the "critical functionality missing" scenario: #if DEBUG #define TODO(msg) #else #define TODO(msg) #error msg #endif Works like a charm. I've got another PRERELEASE() macro that lets you do an unofficial preview build, but would break an official stable release.

Macros cannot expand to preprocessing directives. This does not result in a #error-directive, this just results in a syntax error because of an unexpected # token. A better definition would be something that highlights that message in the error output, such as static_assert(0, msg).

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

#167

Post by vbezhenar »

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.

Intellij Idea has this feature as well. Also it checks for new TODO comments when you commit and warns you about them, so you won't forget to fix if you wanted.

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

#168

Post by alkonaut »

mytailorisrich wrote: post #143
alkonaut wrote: post #139

Earlier quoted context omitted.

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.

A code base that will ship in 2 years will be shipping for various non-production reasons until then. There will be stakeholder demonstrations and alpha releases and things where the code must be functional (runnable), but it may not be production ready in terms of completeness, security etc.

The "accumulation of issues" is there regardless. Leaving TODO's isn't cutting corners or accumulating technical debt. It's simply something that is still to do. Any project will have an issue management system with outstanding issues, but a note in the code is worth more than a thousand words in an issue. "TODO: here is where the validation of parameters must be done, see issue #123". or "TODO: enable right-to-left in these two textboxes when right-to-left text input is added, see issue #234".

There is no value in keeping a main branch "clean" from TODO comments because it's somehow more hygienic. The code needs to be runnable at all times, even with incomplete features. Reaching zero TODO's before a product ships is a matter of grepping for the strings.

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

#169

Post by sullyj3 »

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…

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

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

#170

Post by mytailorisrich »

alkonaut wrote: post #168
mytailorisrich wrote: post #143

Earlier quoted context omitted.

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.

A code base that will ship in 2 years will be shipping for various non-production reasons until then. There will be stakeholder demonstrations and alpha releases and things where the code must be functional (runnable), but it may not be production ready in terms of completeness, security etc. The "accumulation of issues" is there regardless. Leaving TODO's isn't cutting corners or accumulating technical debt. It's si…

You seem to have somewhat diverged from my point, which was a reply to this statement:

> “this is a thing which is okay during development but absolutely must be changed/fixed before shipping this product”.

There is no valid reason to submit effectively defective code to the main branch. There is a major difference between incomplete functionality, which obviously is what the codebase contains during development, and defective or sub-standard implementation.

As an example (and from one of your examples), leaving validation of inputs "for later" is a sure way of shipping code that does not validate inputs and, again, there is no reason not to properly implement this from the get-go.

This sort of issues only accumulate if you let them by cutting corners.

Real-life example: I saw things like "TODO: Check for null pointers" in code. This should be rejected outright during code review. If you should check for null pointers, then do check for null pointers.

Post reply on HN