
The Linux codebase has over 3k TODO comments, many from over a decade ago - patrickdevivo
https://todos.tickgit.com/browse?repo=https://github.com/torvalds/linux
======
jonny383
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.

~~~
TeMPOraL
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 this to be a part
of cleanup after a main task - I go over all the TODOs in the area I worked
in, and implement the simple ones, delete the stale ones, move the serious
ones into issue tracker, and leave the rest for future reference.

All of this applies also to FIXME, HACK and NOTE comments - three other types
I use. Out of these, NOTE are informative, "seriously please pay attention"
comments.

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

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

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

~~~
sergiosgc
I don't understand the need to rewrite history. This is a good example against
that practice.

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

~~~
makapuf
I prefer a small branch with many individual commits (cleaned from fixups or
not) and a merge with main branch which adds the whole feature. Then you can
have two levels of reading.

~~~
drchickensalad
Doesn't this still put all the commits on the main branch?

~~~
makapuf
No you commit in feature branches then merge to main branch.

~~~
abricot
Do you then keep the branch around forever?

~~~
nitrogen
The branch history is preserved in the commit graph of the main branch, so you
don't need to keep the feature branch.

------
slimsag
Interesting! I got curious about where they come from, so I dug a little. Here
is a non-exhaustive breakdown:

\- 23 from crypto code:
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:1000+file:crypto/&patternType=regexp)

\- 2380 from driver code:
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+file:%5Edrivers/&patternType=regexp)

\- 73 from ARM arch code:
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+file:%5Earch/arm&patternType=regexp)

\- 43 from x86 arch code:
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+file:%5Earch/x86&patternType=regexp)

\- 114 from other arch code:
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+-file:%5Edrivers/+-file:crypto+-file:Documentation+-file:%5Earch/arm+-file:%5Earch/x86+file:%5Earch/&patternType=regexp)

\- 606 from block IO, FS, networking, and other sources:
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+-file:%5Edrivers/+-file:crypto+-file:Documentation+-file:%5Earch/&patternType=regexp)

~~~
booleanbetrayal
Without auditing, driver code makes sense to me. Guessing there is a lot of
vendor churn and therefore a lot of caveats to keep track of ... right up
until the point the driver is obsolete and put on life support, never be
looked at again.

~~~
simias
Or simply the features are never needed so they are never implemented. There's
rarely a perfect match between the hardware capabilities and the OS interface,
that's the cost of the abstraction. Sometimes there's no trivial way to expose
the feature or it would require too much work for something that's not deemed
necessary.

------
jandrewrogers
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 for
_optimization banking_. In performance critical applications, this is the
practice of pervasively tagging (often with TODO) micro-optimization
opportunities in the code. When a bug fix or new feature unavoidably creates a
significant performance regression (I use 5%), you implement several of the
"banked" optimizations documented as TODO in order to bring performance back
to parity. For this reason, a TODO may linger in the code base indefinitely
_and that is okay_. It is a searchable annotation for code work that may never
need to be done.

You do not put these kinds of TODO items in an issue tracker because they are
extremely local and contextual to the code they apply to. Filling the issue
tracker with thousands of these kinds of issues which can't be understood
without looking at the specific lines of code the comment was applied to has
high overhead with negligible value. You _do_ open an issue in the tracker for
performance regressions in a subsystem, or if you want to improve the
performance by some metric, which directs a developer to start looking at the
banked optimizations in the TODO comments inside the code.

Another rarely discussed use case for TODO is assumption verification around
the internal behavior of external dependencies. Developers make assumptions
about code dependencies (e.g. Linux syscalls or compiler code generation)
based on trivially observable and testable behaviors. For code that needs to
make strong assumptions about dependency behavior for robustness, it is
frequently impractical at the time of writing code to verify that assumptions
hold under all conditions or that they will remain true over time (see: Linux
fsync() behavior). This becomes an issue that is never "resolveable" in a
meaningful sense because it is a moving target and time-consuming to research
for any particular case. The TODO is a reminder to re-verify behavior if
anything has changed in the software environment or a new bug has shown up and
usually notes what _has_ been verified in the past.

Feature and bug work belongs in an issue tracker but there are many "issues",
particularly ones that are non-functional and require extremely local context
or can never be properly resolved, that are often best served in direct code
annotation.

~~~
tomlagier
> You do not put these kinds of TODO items in an issue tracker because they
> are extremely local and contextual to the code they apply to. Filling the
> issue tracker with thousands of these kinds of issues which can't be
> understood without looking at the specific lines of code the comment was
> applied to has high overhead with negligible value.

This is one thing that really irks me about most code review cultures I've
worked in - they can never stand to see a "naked" TODO (one without a
reference to a tracking bug). You're spot on about the result.

The instinct to put a TODO is a note to self that there is a future cleanup,
optimization, or improvement. It's a flag to readers of the code that the
original author was not quite satisfied with some dimension of a solution. It
is _not_ a work ticket, especially in the timeframe that most issue trackers
work on (< 1 year).

Maybe there needs to be alternate semantics for these "contextual TODOs", so
that people do not immediately get the instinct to either put them in the
queue or remove them.

~~~
boudewijnrempt
Yes... My own codebase has 669 XXX's, 227 FIXME's and 1564 TODO's... For just
615,981 lines of code. And that's valuable information during development.

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

~~~
mewse
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 ones by searching for longer strings of hashes.

Twenty years later and I’m still doing that in my personal projects.

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

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

~~~
Jach
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](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.

------
war1025
In my opinion, any comment prefixed by TODO, XXX, or the like should not
survive past the review stage. Either fix the problem immediately or accept
that it's going to be wonky forever.

Edit:

Amending here to avoid replying to ten different threads individually.

1\. Long-term improvements should be managed by a ticket tracking system. The
code is not the correct place to manage that.

2\. Most of the disagreements below seem to come down to nomenclature
differences.

In my own work, the code is liberally sprinkled with "Note:"s. These are, as
others have pointed out, useful for providing context of what is going on,
why, how it is non-optimal, etc.

TODOs that I come across tend to be of the "You ain't gonna need it" variety.
If you can get a pull through review as-is, then the thing wasn't actually a
"TODO", and if it was, then it should be added as a ticket to the backlog.

XXXs tend to show up in the reviews I do as code that is explicitly meant to
be fixed before the pull is merged.

So to summarize:

1\. "Note:"s in code are great.

2\. "XXX" shouldn't survive the review

3\. "TODO" should be handled by the ticketing backlog to better separate out
"actually needed" from "theoretically nice, but not necessary in practice".

Further, things that are "TODO" today often make zero sense as "TODO" in a
year when the code has grown and evolved more, but since someone put it in as
a TODO, I find that they rarely ever get removed since "surely someone knows
what that means" (but that person is usually either gone or no longer
remembers).

~~~
sedatk
I agree and don't understand people who downvote you as a punishment for
expressing your opinion.

A TODO item is missing significant business information: date, priority,
severity, risk, impact, applicability etc and leaves all those assessments on
developer's shoulders who shouldn't have to deal with it at all.

As a matter of fact, every time a developer encounters a TODO around the
change he did, it suddenly becomes a burden. He needs to answer "should I be
doing this?", "what's the business impact of adopting this?" etc. Even a
simple code change can mean business impact in large projects and has
regression risks. What if the aforementioned developer isn't at the right
caliber for the task, but they don't know it and take it on?

Due to the missing information, it's very hard to analyze TODO data and come
up with reasonable engineering decisions too. TL;DR: It makes everyone's job
harder.

I only find TODO's suitable for personal projects where you don't want to go
back and forth between IDE and the issue tracker.

~~~
IggleSniggle
You have almost converted me from using TODO. I typically place a "Note:" when
there's code that is hacky but not obviously so, to provide context. I also
make sure to provide a link if some kind to a relevant issue tracker.

But a TODO is something different. It's for prototype code, where I don't even
know if the feature is going to stick around long enough for the hack to
warrant fixing. It says "don't worry about just deleting this whole thing
outright and starting fresh." It's graffiti to intentionally make the code
uglier, so it's not confused for being part of some larger design. It says,
"hey, so, I didn't actually expect this code to survive, but since you're here
reading this, it clearly did, you're probably working on something related to
it, and you might want to know a few things upfront because it's not going to
go the way you think it should go."

~~~
sedatk
"Note:" comments are perfectly fine. On the other hand, I've seen at least
three distinct definitions for TODO in this HN thread:

\- TODO should be a note about behavior.

\- TODO should prescribe a small fix.

and yours: TODO should mean "don't worry about deleting this".

These different interpretations and potential confusion they would create make
even a stronger argument against TODOs.

~~~
IggleSniggle
I'm afraid "don't worry about deleting this" was poorly phrased...but your
point still stands

------
kyrra
Chromium has 26,000:
[https://cs.chromium.org/search/?q=%22//+Todo%22&sq=package:c...](https://cs.chromium.org/search/?q=%22//+Todo%22&sq=package:chromium&type=cs)

~~~
mcqueenjordan
Which makes sense since TODOs tie in to buganizer at Google.

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

~~~
Toury2d
That doesn't sound like it would scale at all for any more than a couple of
devs.

~~~
john_moscow
Neither do TODO comments. This is just for a short-term "don't forget this
piece before calling the current job done".

For anything more long-term you want to use a proper task management system
with priorities, deadlines, dependencies and so on.

------
patrickdevivo
Creator here - this was a total pet project and no idea it'd hit the front
page. Upgrading the infra now to handle the load . Sorry for the error rate

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

And that is ok.

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

~~~
Forge36
When the file is next edited by the next individual. They don't need to be
tracked

~~~
StuffedParrot
Sure, and then you end up with linux.

~~~
rumanator
> Sure, and then you end up with linux.

You mean the most successful software project in the history of mankind?

~~~
StuffedParrot
By some metrics, sure.

------
l1k
FWIW, having a TODO file is mandatory for anything in staging/, see
Documentation/process/2.Process.rst.

[https://www.kernel.org/doc/html/latest/process/2.Process.htm...](https://www.kernel.org/doc/html/latest/process/2.Process.html#staging-
trees)

Moreover TODOs are added for unmaintained drivers outside of staging/ in order
to prepare for their relegation to staging, e.g. see commit a0d58937404f
("PCI: hotplug: Document TODOs").

[https://git.kernel.org/linus/a0d58937404f](https://git.kernel.org/linus/a0d58937404f)

------
jcims
Only ~3,000? Not really that surprising, is it? I think a more interesting
metric is how many TODOs have been resolved/removed in that time. I have no
interest in figuring out how to figure that out though, so...

~~~
Psyladine
Couldn't you take an older kernel and do a comparison of the TODOs in the most
recent, and get a count like that?

~~~
jcims
That would tell you how many of the TODOs from that specific older kernel have
been fixed. But in the intervening releases you could have TODOs come and go.
To find them all you would have to go through pretty much every kernel patch
looking for something approximating the following regex (assuming you were
looking at TODO comments and not +/\- TODO files):

^-(?!--).*TODO

This should show you all lines removed from source that contain TODO, which
should get you in the ballpark.

------
dws
The codebase that has no TODOs has no vision of its future.

~~~
geofft
Your vision of the future should be in a bugtracker, not in code comments.
TODOs give you a vision of what you would do if you had a few more hours. A
bugtracker gives you a vision of what you would do if you had a few more
years.

(Where do you put "TODO: Learn tool X and rework all of this to be completely
different using that tool if it makes sense" or even "TODO: The program
crashes at shutdown with a double-free, but I don't know which line of code
had the extra call to free"?)

~~~
talaketu
I have completely the opposite opinion! Any bug in the bug tracker hanging
around "in a few years" should* be closed. Comments should* persist while the
source code issue to which they refer remains remarkable.

*it's fun issuing such rulings.

~~~
geofft
Closed bugs are still easily searchable in just about any bugtracking system,
whereas deleted code is much harder to dig up (you're less likely to even look
for it, and if you do it's harder to find the relevant parts).

I agree that closing bugs you don't intend to act on soon is reasonable; I
disagree that this makes it not worthwhile to have filed it.

FWIW I also agree that todos _specifically about certain lines of code_ , i.e.
todos that will become irrelevant if the code is rewritten at all, should be
in code. The limit of that is probably roughly "TODO return the right error
subclass". Even "TODO pass more information into this function" is probably
past that limit, since it affects at least two spots in the code.

------
jwiley
I used to be pro-TODO, I find myself today firmly in the no-TODO camp.

I work daily on a large, mature code-base, littered with cryptic TODOs left by
developers long-gone. They are generally as useful as street-signs in a ghost
town.

TODO: clean this up

toDo: validate once ARF-211 is closed

todo remove

TODO factor

TODO: lol, hae to enable in production for some reason

TODO- will this scale? logarithmic?

If I dive into the commit logs, I can try and sus out why they were there,
whether they can be removed or acted on. Generally other devs don't touch them
out of superstition, they are probably there for a reason, someone else
understands them, and they will eventually be useful.

Clearly, better team agreements, discipline, strict code reviews etc could
have prevented this or made them more useful, but that ship had sailed before
I arrived, and given the pace of maintenance and new feature development I am
sure these TODOs will remain for quite some time...monuments to earlier days
and priorities that are long gone.

~~~
lucideer
Your anecdotes are familiar and I completely agree with some of your
observations on the limitations of TODOs, but I don't see any reason to be
anti-

As far as I can gather, you've described TODOs being _useless but harmless_

------
modeless
The more interesting statistic would be: how many TODOs have been _removed_
from the code, and were they implemented, or just obsolete/wrong?

------
jbjorge
If you don't use an issue tracker, then to-dos is your issue tracker.

If you're using an issue tracker as well as to-dos in the code, then you've
got two issue trackers.

If you're using an issue tracker that also reads to-dos in the code, then
you've got one issue tracker.

Where I work we don't have an integration between the tracker and our code, so
we disallow to-dos, but allow comments with references to issues. So in other
words - one issue tracker.

I can't quite understand why people would want to have multiple places to list
code issues.

~~~
kjeetgill
In practice they work quite differently in a number of ways, depending on your
workflows. I'll outline mine, but from this thread you can probably tell, it's
not unique.

Jira/Github-like issue trackers can often become blackholes for certain kinda
of work. Not all TODO's NEED to get done, they're often just reminders to
revisit decisions with the full context of the code. The two most common cases
that come to mind are deferred possible optimizations and deferred
generalization.

In my workflow, it's more of a counterbalance against premature optimization,
abstraction, and distraction. It also has the benefit of:

a) informing reviewers what wasn't done and why right in the diff. It can
often spark good conversations of if it's worth scoping them in or maybe
scheduling in (Jira!) soon.

b) Allowing people to revisit the above when the next engineer is changing
things in the neighborhood.

In my experience, if and engineering side ask isn't addressed in a month or 2
it quickly turns into one ticket that sits in the backlog forever and maybe
another that get's created when the "idea" get's floated again.

Naturally, your milage may vary.

------
dgellow
A small rule that we set at $WORK, that I found quite helpful for comments:
always require a Jira ticket ID if you add a TODO comment.

That way you always have `// TODO (PJ-1234): better to have some caching
mechanism`, where `PJ-1234` is a ticket with "TechnicalDebt" tag, and more
details/context.

That gives some transparency to the rest of the team (outside of people
working on this specific code base), and avoid situations where nobody knows
why a TODO comment exists.

------
efnx
This is why I wrote [https://srcoftruth.com](https://srcoftruth.com) \- it
will find your todos and open, track and eventually close a ticket for each
distinct todo in your repo. Works on GitHub repos and issues (private and
public). Currently building JIRA integration and generic web hooks. And it’s
free!

------
mlindner
I don't understand the hatred for TODO statements (and similar), even if you
never come back to them, they're still useful to know the future intention of
the original author.

~~~
james_s_tayler
I agree but I also think that value is pretty marginal.

------
buybackoff
When I see just a simple `TODO` in some OSS project it's often hard to
understand either it's a broken edge case or some micro optimization or
refactoring left for future. For my projects I adopted (it grew naturally)
priority tags, e.g. `TODO!!! [(WTF)]` for critical [tricky/edge case] bugs,
`TODO!` for important hot paths optimizations, `TODO (low)` for nice to have,
`TODO?` or `TODO (review)` for rethinking design later.

Actual tags are not as important as ability to understand the priority at a
glance without looking up a tag in some docs. And fixing all `TODO!*`s is high
priority, ideally they should not be committed.

~~~
jjgreen
That's a great idea, I'm going to give it a go myself, thanks!

------
sethammons
I'll litter my code with TODOs while developing, especially in a green
project. However, our team has a practice that we find valuable: any TODO
checked into the master branch must contain a link to a jira ticket. A TODO
that can't be prioritized is likely to never get done. We like the forcing-
feature of making the choice to handle it now, or working to get it
prioritized.

------
katzgrau
TODO, aka I have the best of intentions but I'm probably not doing this in the
near future or ever, for that matter.

I'm guilty for quite a few

------
peterwwillis
A lot of people suggesting "TODOs should become tickets before accepting the
code for merge". So... How do you do that? Manually, I assume?

A while ago I started on a tool to automate managing GitHub Issues, but the
libraries and tools around issues were mostly crap, so I stopped. But I'd love
to get a generic tool together to manage issues using single lines in a text
file (such as code comments, or Markdown lists), such that editing a line in
the file causes the tool to create, update, close, or delete issues.
Infrastructure as Code, but for issues/tickets.

You could then script pre-commit or pre-merge hooks to create issues for TODOs
on the fly, and later on have a job skim though code and delete TODO comments
whose issues had been closed. Extend it to use Jira and you can use it at
work, too.

------
patrickdevivo
For anyone interested, I wrote a piece last week taking a look at the 2k+
TODOs in the Kubernetes source code as well:
[https://medium.com/@augmentable/looking-at-
kubernetes-2k-tod...](https://medium.com/@augmentable/looking-at-
kubernetes-2k-todo-comments-b2db42dc7fdb)

Most were from over a year ago.

I don't think TODOs are bad practice, and I've seen a diversity of opinions on
them in the comments of various posts. I think they are notoriously forgotten,
and major codebases like linux and k8s are no different.

Aggressively stale TODOs though are likely an indicator of an area of code
that should probably be revisited or cleaned up.

------
cjfd
The 'many from over a decade ago' part shows one problem with TODO comments.
Very often these TODOs are never done. Really, TODO comments should not exist.
When you are writing some code is the point when you know most about it and is
therefore also the best point to write code of optimal quality. Also, for some
TODOs I encounter in the wild I cannot really shake the impression that the
author is showing off by suggesting something that sounds smart but actually
is impractical and should never been done.

------
bryanrasmussen
At a former work we had points for what got added, fixing TODOs was worth 2
points IIRC. We were a small team and people were all good - probably wouldn't
work in every situation.

------
Lammy
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](https://i.imgur.com/QAYtrVB.png)

~~~
xeeeeeeeeeeenu
On my end the URL is
[https://todos.tickgit.com/browse?repo=https://github.com/tor...](https://todos.tickgit.com/browse?repo=https://github.com/torvalds/linux)

Perhaps your problem is caused by some browser addon.

------
Twirrim
Out of curiosity, I grabbed a copy of the repository and did some basic
searching.

    
    
        $ egrep -icr "\bTODO\b" * | tr ':' '\t' > ../todos
        $ cat ../todos | awk '{sum+=$2;} END{print sum}'
        6372
        $ grep "^Docum" ../todos |  | awk '{sum+=$2;} END{print sum}'
        1172                                        
    
    

So roughly 18% are in Documentation. The biggest culprit is
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/features/debug/user-
ret-profiler/arch-support.txt) , because user-ret-profiler appears to only
support x86. All other architectures are in as TODOs

    
    
        $ cat ../todos | sort -n -k 2 | tail
        Documentation/features/debug/user-ret-profiler/arch-support.txt 24
        drivers/media/dvb-core/dvb_ringbuffer.c 26
        drivers/platform/chrome/cros_ec_spi.c   33
        drivers/media/dvb-frontends/drx39xyj/drxj.c     34
        drivers/media/pci/ttpci/av7110_av.c     34
        net/ieee802154/nl802154.c       35
        drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c     40
        drivers/android/binder.c        48
        drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c       51
        drivers/net/wireless/broadcom/b43/phy_n.c       54
    

The biggest single-file culprit for TODOs is in the broadcom b43 drivers,
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/broadcom/b43/phy_n.c).
From what I can clean from phy_n.c, it looks like it's because the linux
kernel can't handle revision 19. There's a lot like:

    
    
         if (dev->phy.rev >= 19) {
          /* TODO */
                } ...
    

or

    
    
        static void b43_nphy_tx_cal_radio_setup_rev19(struct b43_wldev *dev)
        {
         /* TODO */
        }

------
topmonk
I always write TODO statements with a number from 1 to 4, indicating the
severity.

1 is immediate, meaning it needs to be fixed for the system to work.

2 is something that should be done before release.

3 is a near term wish list sort of thing, and

4 is a hopeful, probably never sort of thing

In addition, another place I deviate from the norm is when I comment out code,
I write the reason why it's commented out.

These two things really help keep my code from becoming incomprehensible as
time passes.

~~~
nfoz
That sort of convention sounds fine for a solo project, but I think if you
have more or changing developers then it would make things more confusing.

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

------
shp0ngle
The number of FIXMEs seems about half of that, from a quick glance.

FIXMEs :
[https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+FIXME.*%5C:+case:yes+count:1000&patternType=regexp)

------
jedisct1
I've never seen "TODO" / "FIXME" sections ever being eventually done/fixed.
Never.

------
kitsuac
Most anything you do, in general, will fork off into many branches. Some being
required dependencies and many others being tangential improvements or
generalizations.

You can either note them in some way as they emerge, or ignore them and keep
your code tidy of such notes.

------
michelb
I'm curious to learn how this is with other large codebases, or operating
systems at Apple and Microsoft. I imagine the amount of open bugs or todo's
will be much larger, many also from decades ago with no chance of ever being
touched.

------
mastazi
Link not working for me. I’m getting this:

Error: Network error: Origin
[https://todos.tickgit.com](https://todos.tickgit.com) is not allowed by
Access-Control-Allow-Origin.

------
magwa101
Hilarious! I remember working on early Unix OS implementations in the 80s.
When I saw all the TODOs and NEEDSFIX and WHOKNOWSWHAT I was thinking "How do
I make any mods to this?"

------
gotoeleven
Well hopefully TODO compilation will be in the next C++ standard.

------
mlang23
Isn't this a nice case against comments in code? Everything that your compiler
can't parse is a waste of time. Where is #todo if you need it?

------
agumonkey
Let's add one not to forget reducing their amount

------
shrimpx
It could be a red flag or nothing depending on the development culture around
the project and how they assign meaning to these comments.

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

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

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

------
sharma_pradeep
I have in similar no. o TODO in a 3 yr old codebase. And also 100s of
warnings: "Don't touch if it's working"

------
bythckr
3k TODOs in a vital opensource project. Why? Lack of funding or lack of coders
or Linus/Stallman(FSF/GNU, who has resigned but is he replaced?) is unable to
be everywhere and he need a bigger team to support him? What is the "news"
here? Is it a warning to avoid Linux's possible "Heartbleed" type issue?

------
tjpnz
Might these present an opportunity for those wanting to contribute?

------
thrower123
I'm amazed it is that low.

There's always stuff that wants doing, but not just now. Except now doesn't
come, and those todo notes, like most comments, get ignored forever, peoples'
eyes skipping straight over them like they were never there.

------
keyle
I guess all the FIXME and HACK have to be addressed first :)

------
known
I think Students could use them as homework/assignment

------
jameson
later means never :)

------
randyrand
todo's are often for future perf or better ways of doing the same thing. Would
be nice if todo's were annotated with a category.

------
tomrod
How many in the Windows or Mac codebase?

~~~
noisem4ker
I'd also like to know. It could be a nice addition to this paper, in case of
an update:

[https://blogs.msdn.microsoft.com/iliast/2008/05/16/code-
qual...](https://blogs.msdn.microsoft.com/iliast/2008/05/16/code-quality-
windows-vs-linux-vs-freebsd-vs-solaris/)

------
Jahak
Error: GraphQL error: connection error

~~~
patrickdevivo
Sorry about that! Didn't realize this would hit the frontpage, infra should be
upgraded!

------
panpanna
TODO: do something about all those TODOs in our codebase.

This could make an excellent XKCD.

Edit: to turn this into a more useful comment, let me add that TODO is an
important component of test-driven development. If you read Kent's original
example with Fibonacci you will note that he splits the functionality into
multiple small milestones.But unlikes traditional waterfall these appear
organically as TODOs in the test and implementation code as things progress.

