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

291–300 of 301 posts

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

#291

Post by dragonwriter »

Jach wrote: post #107
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…

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.

> Using code comments really seems like the wrong place to prioritize changes.

It's a poor place for long-term tracking, but it's a great place for recording notes while minimizing context-switching cost while coding.

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

#292

Post by m463 »

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…

That seems very nice, as long as you remember XXX FIXME comes first.

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

#293

Post by jcelerier »

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.

But then does it matter at all that the date of the comment was the day where you committed the todo, or two days after when you squashed it ?

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

#294

Post by [deleted] »

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.

[deleted]

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

#295

Post by DecoPerson »

arthurjj wrote: post #280
jandrewrogers wrote: post #265

The kind of software being written materially influences the semantics and use cases for TODO. I think much of the disagreement in this comment thread is based on a tacit assumption that everyone works on the same kinds of code bases. A web app is not the Linux kernel, and the priorities and concerns in development when annotating code will differ. For example, in much of the database code I work with, TODO is used f…

Recently at a social gathering of programmers TODOs came up and we all had dramatically different practices Defense contractor: TODOs don't make it past CR. This is a heavily regulated industry with yearly release cycle Embedded: TODOs can make it to nightly builds but not final/released build Web: TODOs are fine, fix them as needed.

Games: Don't fix the todos. You'll ruin the secret sauce.

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

#296

Post by heavenlyblue »

dev_tty01 wrote: post #284
heavenlyblue wrote: post #177

Earlier quoted context omitted.

To be fair, I believe many projects simply lack the second set of eyes which would downgrade those TODO to basic comments or along the lines of FUTURETODO

Too much typing. Try FUDO.

This is more of a bikeshedding question, but I’d go with NOTE instead.

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

#297

Post by thu2111 »

derefr wrote: post #255
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…

> 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. It sounds like the ideal thing to do here, in order to stay in flow, is for these notes to be inline TODOs while coding ,…

Beyond it being pretty fragile to have pre-commit hooks edit code, the problem is TODOs are usually very context sensitive. They are usually only understandable given the surrounding code and part of their benefit is they follow refactorings. Tickets wouldn't have that.

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

#298

Post by thu2111 »

war1025 wrote: post #42
newnewpdro wrote: post #21

Earlier quoted context omitted.

And your kernel would likely never ship, at least not with many drivers anyways. Don't forget Linux is largely a grassroots effort with heaps of reverse-engineered or otherwise improvised/ad-hoc hardware enablement going on. It wasn't until relatively recent history that we could even suspend/resume reliably!

Some form of tracking tool is the correct place to document the roadmap, in my opinion. The roadmap can be continuously monitored and updated. TODOs in code just end up as comments that exist for a decade because no one along the way wants to delete them, even if they have no relevance anymore.

Whereas every issue tracker ever has no abandoned or ignored pile of ancient tickets?

Must be a nice place to work! Because I've never seen anything like that before.

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

#299

Post by yoloClin »

james_s_tayler wrote: post #81
yoloClin wrote: post #60

Earlier quoted context omitted.

Is there a standard for valid flags? I recently recommended a client use `TODOSECURITY` for todos which had security implications until fixed - I discovered functionality which was implemented before authorisation had been developed, resulting in a codepath which was unintentionally reachable by standard users. Seemed weird to make up a codeword but I wasn't aware of any standard convention, and visually highlighting…

Open a ticket for that straight away and start working on it immediately. Or 3 years later. Whichever actually happens.

Yeah, that's probably true. I don't have any visibility over that particular projects ticketing system but I imagine it was never raised given it wasn't fixed until I noticed it.

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

#300

Post by yoloClin »

sophiebits wrote: post #95
yoloClin wrote: post #60

Earlier quoted context omitted.

Is there a standard for valid flags? I recently recommended a client use `TODOSECURITY` for todos which had security implications until fixed - I discovered functionality which was implemented before authorisation had been developed, resulting in a codepath which was unintentionally reachable by standard users. Seemed weird to make up a codeword but I wasn't aware of any standard convention, and visually highlighting…

I’d strongly recommend not landing code that has known security problems.

It was my job to look for security problems.
Post reply on HN