Live data from Hacker News

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

todos.tickgit.com

101–110 of 301 posts

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

#101

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.

Nice! Isn't this exactly assert in C++? (the following is from https://en.cppreference.com/w/cpp/error/assert ) #ifdef NDEBUG #define assert(condition) ((void)0) #else #define assert(condition) /*implementation defined*/ #endif ... assert(("There are five lights", 2 + 2 == 5)); ... test: test.cc:10: int main(): Assertion `((void)"There are five lights", 2+2==5)' failed. Take it as a token that you are doing something…

Assert's run-time. This is compile-time (i.e. all instances are guaranteed to trigger during build). C++ equivalent would be a static_assert, but it has a totally different use case like this:

  static_assert(sizeof(StructUsedInSomeBinaryProtocol) == SomeConstantExpectedByTheOtherSide, "")

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

#102
post #73

Meta: What's up this the URL on this post? The URL is just to the root of Linus' kernel repo on github, the HN sitebit is 'tickgit.com', but from the comments I figured out the actual submission is supposed to be sourcegraph.com and that nobody else seems to have any issue getting there? https://i.imgur.com/QAYtrVB.png

On my end the URL is https://todos.tickgit.com/browse?repo=https://github.com/tor...

Perhaps your problem is caused by some browser addon.

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

#103
post #9

> The Linux codebase has over 3k TODO comments, many from over a decade ago And that is ok.

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

Every codebase is like this because it's cheap to open tickets and pepper the codebase with TODOs but orders of magnitude more expensive time-wise to actually do the work. The method of storing the information and prioritizing the work is irrelevant. You simply don't have enough bandwidth to do it all and some of it simply isn't materially important enough to ever get prioritized.

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

#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 some improvement or method, my brain typically needs to context switch to focus on the fine details of the subject. By the time this is done, and I switch back, I have forgotten key aspects of what I was working on and it slows me down again (i.e. local names, structs, etc.)

3. It allows me to re-approach something with a completely different mind set (given that I come back to it after a signicant amount of times). Half the time I realise that what I wrote was indeed "good enough" and no further time should be committed to it unless a reason exists to do so.

4. It gives opportunity for other developers to see, think, comment and contribute on the subject. I find that typically if I TODO an area, it's good for a second set of eye balls to see it. There's far smarter people than me around, and there's a good chance one of them will find it and propose a better solution.

5. On the rare "quiet" day, I can grep for TODO and just work through them.

Obviously these points are only valid if the TODO labels are being added in situations that will benefit from the above.

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

#107
post #100

I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.

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…

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.

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

#108
post #65

Earlier quoted context omitted.

Not for the sake of cleanliness - for the sake of storing the information in a useful format. If you want the bugtracker or documentation to be checked into the same source repository, that seems entirely reasonable to me. I don't know good tools beyond text files for doing this for bugtracking (although I think Fossil does this, kind of, and I'm sad that Simple Defects never took off), though if your work is uncompl…

Most devs I've been working with don't even bother with a full sentence in their commit log. At this point, we're discussing between what "should be done" in a perfect world, and what's actually been done when you switch between a couple of project in a day, moving from "implementing feature Y" back to "putting down some random fire", back to "implementing feature X" within a day in an undermanned team. Sometime, a h…

Oh yeah, a TODO is way better than nothing, no disagreement there.

If you have a code review step, "please move this comment from the code to the commit message / the bugtracker / whatever" seems like a reasonable comment. If you don't or you're bypassing it or nobody does good code reviews, sure, leave the TODO in. I am indeed talking about the ideal world and whether we think TODO comments are a good idea in the abstract.

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

#109
post #107
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…

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 don't really want to use a bug tracking system on my personal projects, though, so I can see why someone would choose to do the TODO or hash idea

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

#110

I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization." It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.

For small projects without issue tracking, I use TODO for this iteration (or soonafter), and WISHLIST for "would be nice" future optimizations.

Might I suggest you give a chance to having separate TODO and WISHLIST and TASKS text files in the root folder that use whatever id scheme you like and point to the code, with the code referring back to those ids only rarely? Or even a single file with sections for those things and more, perhaps called PLAN? Keeping things separate keeps the code tidier, gives you license to put more details than you're likely to put in a one or two line comment, lets you refer to multiple code points instead of the local comment area, can be given to a high school student temp worker, and so forth.

For personal projects I've used https://github.com/dspinellis/git-issue a few times for a local command line issue tracker, it's not bad. I've got a longstanding mental TODO to try out Fossil one of these days though with all that and more integrated...

Post reply on HN