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?"
The Linux codebase has over 3k TODO comments, many from over a decade ago
281–290 of 301 posts
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#282I 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 int…
I understand your point, and I'm probably overreacting, but words like 'pro-TODO', 'no-TODO camp' makes the topic more binary than it deserves, and to some extent urges people to pick sides when it's really not necessary - we're all here to learn something, not to point fingers.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#283Earlier quoted context omitted.
Serious question as someone who drops XXX occasionally: There are all sort of places where you want to note "there's probably a better way to do this" or "maybe look at this edge case" or whatever. Not all of those are important enough to address in the next review/sprint/whatever...why isn't it better to leave them in and keep that tribal knowledge around rather that delete them and loose that insight? Maybe a bette…
I prefer to minimize tribal knowledge of all forms. This does incentivize deletion over "it might be somewhere/in someone's mind", but it also incentivizes moving the knowledge out of the jungle and into something longer lived and searchable in a broader context. How much I prefer the minimization depends on the size/stage of the company, though... At early startups for instance, most tribal knowledge will take care…
Thanks for taking the time for that detailed response. It seems to me the underlying theme here is "strive for more maturity in the development process". Good lesson.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#284Earlier quoted context omitted.
Your points are valid, and I've used it as well many times, but ther's always the risk you find yourself in a situation where there's just a growing number of TODO items. Which isn't (always) a problem per se, but severely limits there usefulness and could be a sign of ever-expanding problems all over the code base. Worst I've seen is REALLYTODO popping up, then you know the ship is probably beyond sinking. Then agai…
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.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#285Out 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
$ 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
if (dev->phy.rev >= 19) {
/* TODO */
} ...
static void b43_nphy_tx_cal_radio_setup_rev19(struct b43_wldev *dev)
{
/* TODO */
}Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#286Earlier 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…
I'd rather not lose context of what I'm working on by switching from code to issue tracker. That's how bugs are born.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#287Earlier quoted context omitted.
Out of curiosity, is there any disadvantage in making the TODO comments and then removing them before merging the result into master?
Yes. At that point in time, these comments are by definition a list of things that still needs to be done. Removing that will lead to forgetting it, and may create a false impression that the committed code is 100% complete.
By removing it I mean moving it into the appropriate bug/issue tracker.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#288Earlier quoted context omitted.
Out of curiosity, is there any disadvantage in making the TODO comments and then removing them before merging the result into master?
In my eyes, yes. I'm quite thankful if the code I'm reading is honest and tells me about stuff not up to par with whoever wrote the code/reviewed it expected. With a TODO it can often be easy to figure out if the feature/bug I'm working on is affected by it. Potentially a huge time saver.
That's a fair point regarding visibility. I'll have to reconsider the pluses and minuses because before now I only really saw it as a "too lazy to make a ticket" thing.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#289Earlier quoted context omitted.
There is a pretty simple rule for this problem: Can you do it immediately? Do it now. Must you do it later? Write it down. If you decide to use TODO as a way of writing something down then you must make sure that these TODOs are just as visible as whatever ticket system you're using and that they are integrated into your release schedule.
I disagree. The reason those TODOs appear is because the answer to the question "Can you do it immediately?" is, "yes, I can, but it would break my flow and interrupt what I'm doing right now". The reason some of them don't later get promoted to issues in the tracker is because they're too small or otherwise irrelevant at the project level. Their place is in the code, where the next person looking at it will spot the…
Then it is not a TODO, it is a NOTE. Don't act as if it will be _done_ magically in the future. If I stumble upon a TODO, I won't fix it (because it will diasrupt my flow - the reason for the TODO in the first place). And if it is not in the issue tracker, I can't plan for it. A solution would be some kind of an "implement as many TODOs as possible" time-boxed spike, but this never worked really well for me in the past.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#290Earlier 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…
Exactly. TODOs should be an adjunct to the issue tracker. An issue could be "Clean up/resolve all TODOs in module qux". but each of those comments on there own are rarely worth the issue on their own. Also not every project has the FTEs or the scope to hit every TODO in the first pass. Maybe it's all a glorified demo and these are "Road closed" points to be enhanced/hooked in to in the future.
> An issue could be "Clean up/resolve all TODOs in module qux". but each of those comments on there own are rarely worth the issue on their own.
In my experience, this doesn't work. How many story points does it take to solve _all_ TODOs in a module? How many modules are there? How do I explain this task to a manager or stakeholder? How do you handle TODOs that you think are nice-to-haves or even unnecessary (while your collegue may disagree)? What about TODOs that you do not unserstand (because it is often a one-liner). All those points are mostly solved by 1. Extracting important issues into a ticket OR 2. Commenting the code with a NOTE (instead of TODO), admitting it is not cost-effective to implement. The comment is there as an info for future developers, but it does not look like task that just waits to be implemented.