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

241–250 of 301 posts

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

#241

Post by dudus »

ygra wrote: post #124
dudus wrote: post #91

Earlier quoted context omitted.

TODO, FIXME and XXX are built into tools already. Sure you can make new stuff up but it makes it harder to find later.

Those things are configurable, though, so new markers are rarely problematic from a tooling perspective. Getting your teammates to agree on using the same markers is perhaps the bigger problem.

Making them agree is not necessarily the hardest. But remembering to tell new team members in a year or two. Or revisiting the codebase in 5 years from now. I doubt you'll remember

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

#242

Post by mannykannot »

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…

The situation you have described, with there being versions of the code that must not go live, is precisely what branches are for, and branching is cheap. Whether you should consider the particular branch named 'master' to be special in any way, is largely a matter of preference, though if you end up with a mature product, it is quite possible that you will want to be able to cut a release from more than one branch.

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

#243

Post by gwbas1c »

jbaudanza wrote: post #3

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.

I think TODOs are fine for small projects, or early code.

HOWEVER: For a mature project, TODOs should be found and reviewed during the pull request. Either they should be fixed prior to merge, or a ticket should be filed. (With a link placed in the TODO comment.)

In the rare case that a TODO remains without a ticket, it really should be something obscure that really doesn't need to be fixed. For example, TODOs are great for micro-optimizations or suggestions for long-term refactoring.

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

#244

Post by asdkhadsj »

speleding wrote: post #239
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 think it makes sense to refine the levels a bit more. We use FIXME, TODO and OPTIMIZE in order of decreasing importance. - FIXME should really not even be committed, except in a proof of concept - TODO should be fixed eventually, preferably before release to production - OPTIMIZE is a "nice to have" that gets fixed on a quiet day Furthermore, TBD (to be done) indicates where new expected functionality is expected t…

I was actually just thinking about implementing this type of importance based flags.

In addition to these, I'd like review stubs. Something like:

- REVIEW: can this be done better?

I'd like junior devs to be able to note things as they're thinking about it, not try and remember it later during review. Especially since there may be nothing wrong with the code, it may be as good as it can get[1], so a reviewer wouldn't catch it. Though, I'm mildly concerned about cluttering up code. I suppose you could just remove them on the fly down the line, since they made it past review and etc.

[1]: As good as it can get.. that the reviewer knows of heh

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

#245

Post by TeMPOraL »

simias wrote: post #221
TeMPOraL wrote: post #159

Earlier quoted context omitted.

Because running git blame on code breaks the flow. Because git blame may give you wrong author and date (say someone edited the code around the note, changing its indentation level; EDIT: or rebased it, as 'daemin says). Because git blame is not a grep-friendly solution. Because code sometimes lives longer than version control systems (I've worked with codebases older than git). Because very often code lives longer t…

I agree with all your other points but I want to point out that if `git blame` breaks your flow I recommend that you look up how to better integrate git with your code editor, it's a huge time saver IMO. With vim-fugitive I can just ":Gblame" on any code I'm currently browsing and immediately I get a side-pane with the annotations for every line. ":Gdiffsplit" shows me the diff between my version and HEAD etc... But…

It's C-x M-g b in my Emacs, but doing this annotates the whole file, which gets distracting enough for this particular purpose. Still, I use it frequently.

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

#246

Post by StuffedParrot »

rumanator wrote: post #126
StuffedParrot wrote: post #92

Earlier quoted context omitted.

Sure, and then you end up with linux.

> Sure, and then you end up with linux. You mean the most successful software project in the history of mankind?

By some metrics, sure.

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

#247

Post by TeMPOraL »

spockz wrote: post #209
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.

At least these days co-authorship can be recorded in the commits.

But then cherrypicking doesn;t preserve commit metadata, does it?

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

#248

Post by ShinTakuya »

TeMPOraL wrote: post #125
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…

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…

Out of curiosity, is there any disadvantage in making the TODO comments and then removing them before merging the result into master?

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

#249

Post by alkonaut »

mannykannot wrote: post #242
alkonaut wrote: post #168

Earlier quoted context omitted.

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…

The situation you have described, with there being versions of the code that must not go live, is precisely what branches are for, and branching is cheap. Whether you should consider the particular branch named 'master' to be special in any way, is largely a matter of preference, though if you end up with a mature product, it is quite possible that you will want to be able to cut a release from more than one branch.

Absolutely you can either designate an unstable “develop” branch and do stakeholder demos from there while keeping master clean, or you can develop on master and ship from stabilization branches. You can have any number of branches and assign any level of quality and polices to each. But you can’t avoid TODOs entirely by keeping them only on feature branches as what you’ll need is a branch with all features integrated but not necessarily shippable.

If you do stakeholder demonstration from an integrated “develop” branch and ship from master, you can have a policy of “no TODOs in master” meaning you won’t ship the TODOs. I’m not saying one must have TODOs ever in the branch-that-will-be-released but that they can be very useful and almost unavoidable to have in some integrated branch, because you may need to show a product without it necessarily being ready. Exactly what quality gates you ship with is a preference, for example specific comment tags (PERF, FIXME, TODO, ...). These are just words. In my codebase TODO means "this works but isn't optimal, so should be revisited IF the code ever has a reason for change". In other codebases it might mean "This is utterly broken and can't be shipped". Whether shipping is acceptable of course depends on which of those interpretations one uses (And using both would be a process error).

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

#250

Post by tjoff »

ShinTakuya wrote: post #248
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…

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.

Post reply on HN