TODO is the prerogative of lazy programmers, who wants others to fix their bugs.
The Linux codebase has over 3k TODO comments, many from over a decade ago
151–160 of 301 posts
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#152I 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. Thes…
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.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#153TODO 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…
> 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
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#154In 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…
I've been in many scenarios where fixing a certain behavior or implementing something in an optimal way requires a change in an external or upstream product. Or it may require a larger refactoring that's in discussion or otherwise outside the scope of the quick fix. "Either fix the problem immediately or accept that it's going to be wonky forever," sounds like a nice ideal but it's not practical to treat it as an abs…
Yep, the todo is there to indicate to future code readers that yes we know this sucks but can't fix it properly yet because of blocker X, so don't try to make a half-assed fix yourself without consulting issue tracker nr ### first.
See it as an index into the issue tracker so you don't have to search the issue tracker any time you come across some really strange code. This could of course be done with normal comments also, not necessarily todo.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#155TODO 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 makes a lot of sense if you are only a few people working the code. If not, maybe spend some minutes at the end of the day to register them as issues? If that’s to cumbersome or difficult, something is wrong in the process or tooling, IMHO. It makes me go crazy when I find todo scattered everywhere - often these todos are short, hard to decipher and ownership and priorities become jumbled. What you describe in the…
RedHat has some tooling that defines a basic format for Todo comments and can be converted to JIRA issues on their Jboss.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#156TODO 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…
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 again, in principle this is no different from growing todo lists, ever expanding issue tracker issues, ... But at least you can search those for context more easily imo.
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#157Earlier quoted context omitted.
It makes a lot of sense if you are only a few people working the code. If not, maybe spend some minutes at the end of the day to register them as issues? If that’s to cumbersome or difficult, something is wrong in the process or tooling, IMHO. It makes me go crazy when I find todo scattered everywhere - often these todos are short, hard to decipher and ownership and priorities become jumbled. What you describe in the…
RedHat has some tooling that defines a basic format for Todo comments and can be converted to JIRA issues on their Jboss.
I actually thought that probably would exist and even be a common thing when I finished writing the comment. :)
I’ll look in to setting something up for my team next week... they like todos!
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#158I have in similar no. o TODO in a 3 yr old codebase.
And also 100s of warnings: "Don't touch if it's working"
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#159Earlier 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 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
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 than the repo it originated in, so you can easily lose history (many new projects get started by copy-pasting pieces of a previous project).
Re: The Linux codebase has over 3k TODO comments, many from over a decade ago
#160Earlier 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 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
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.