9 ms·

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 followin

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.

pg_is_a_butt 7y ago
// TODO!! care.
TeMPOraL 7y ago
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 7y ago
  > 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
  - TeMPOraL 7y ago
    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).
    - simias 7y ago
      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 beyond that I agree completely, `git blame` is not the right way to track the authorship of annotations in a file.
      - TeMPOraL 7y ago
        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.
  - daemin 7y ago
    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.
rypskar 7y ago
I use a macro to create an unit test for reason 1 and 2 and name tests with what to test_conditions_expectedResult and add assertTrue(false) as body. I forget to check for todos before I commit, but a failing test is harder to miss
psalz 7y ago
Great points, especially 1 - 3. For me it is also often not so much about optimizations, but rather additional use/edge cases that might need consideration, but I'm not sure yet because I haven't e.g. fully fleshed out an interface yet. Often times I will ultimately just delete the note (going back to your third point), but other times it might result in an additional test case, for example. Whenever I'm starting out on a new project (which might just be a new module in an existing code base) my mind tends to bombard me with these hypotheticals, so it is tremendously relaxing to just whip up a quick note and know that it will be dealt with by future me :). To actually enforce this, for the past couple of years I've been using NOCOMMIT comments, together with a git hook that actually prevents me from committing those lines. I rely on this workflow so much now that I can't even imagine going back. I also get really nervous in pair-programming scenarios when someone will say "Yeah, I'll change/fix/adjust that later" - all I'm thinking is "but will you remember?!".
- ahartmetz 7y ago
  Instead of NOCOMMIT, I keep the "is it final" bit in short-term memory (maybe helped by reviewing staged changes) and start the commit message with "WIP:" if necessary. It's a convention from the Qt project that its CI understands. The advantage is that it doesn't block other work until resolved. Sometimes what's missing is even a good/better commit message, which is awkward to remark in the code.
- jmiserez 7y ago
  Yes, automatic enforcement is invaluable. Instead of a commit hook you can also use a pre-receive hook on the server. This allows rebasing, wip commits etc. locally and doesn't require any client config.
jordanbeiber 7y ago
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 points above actually looks like an issue tracker to me. When I find todos I tend to cut them and paste them as issues trough slack bot integration. It keeps an ok flow, although I get annoyed that my fellows could not be bothered... To each their own I guess, and whatever works! Edit: I love in-line comments and documentation though. Just not todos. :)
- hashhar 7y ago
  RedHat has some tooling that defines a basic format for Todo comments and can be converted to JIRA issues on their Jboss.
  - jordanbeiber 7y ago
    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!
stinos 7y ago
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.
- heavenlyblue 7y ago
  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
  - dev_tty01 7y ago
    Too much typing. Try FUDO.
    - heavenlyblue 7y ago
      This is more of a bikeshedding question, but I’d go with NOTE instead.
- foobarian 7y ago
  One of the more entertaining activities at work is to make fun of ancient TODO comments in our giant codebase. There are some all-stars most of us know by heart such that they made it into the internal company jargon. Tl;dr we ask to resolve TODOs during code review and don't allow them in now.
ben174 7y ago
Back in my Microsoft development days, I fondly remember Visual Studio automatically adding todo comments to a dedicated little docked window in the corner of the IDE. It was very efficient and would always be in the corner of my eye and I would always circle back to them as a result.
- keyP 7y ago
  I still use this feature, it comes under the "Task List" window. Adds any "TODO" comments in realtime by default but it's also possible to extend what tokens show up alongside "TODO" [0]. I've added "Hack" or "Perf" for temporary implementations that definitely can be improved but not necessarily critical. [0] https://keyboardp.com/post/40190774577/using-task-list-tokens-in-visual-studio-to-improve https://keyboardp.com/post/40190774577/using-task-list-token...
- vbezhenar 7y ago
  Intellij Idea has this feature as well. Also it checks for new TODO comments when you commit and warns you about them, so you won't forget to fix if you wanted.
- yitchelle 7y ago
  It was a while ago since I used Eclipse, but I think it greps all the TODOs in the source code or project workspace, and list them as a list of TODOs :-) for you to work through. Not sure if it still does this but I found it to be a really good feature.
  - fian 7y ago
    Eclipse still has this and even better you can define your own tags that are also added to the list view. You can then filter by tag name in the list view. I found this handy when doing large refactorings (e.g. that took multiple weeks or months). I could define a custom TODO for that refactoring for labeling tasks that I knew I would need to resolve before completing the refactor but was not able to tackle immediately. It made it less stressful knowing I would be easily able to find the tasks again and the central list made it efficient to clear them all.
jpswade 7y ago
A todo is fine, only if there’s a way to get it to done. There must be a plan otherwise it’s a pointless comment.
- agumonkey 7y ago
  How would you call a comment for a potential idea/feature ?
  - jpswade 7y ago
    The code isn’t the right forum for feature suggestions and ideas.
johndoe18637 7y ago
At work we made it a policy to allow TODOs to remain until code review. At least there, with the help of a second pair of eyes, they should be resolved, removed or made into an issue. Until now this approach works quite well for us.
- fierarul 7y ago
  This is a good approach except it breaks the link from the TODO location to the issue. Are you replacing the TODOs with an URL for the issue or something like that? How do you know a file has issues/todos by just looking at the file in your editor/IDE?
  - shantly 7y ago
    Yeah, I dislike banning TODO comments from passing through both for the reason that they're so coupled to the code they reside along that turning them into an issue is rarely helpful, at least as I write them, and that they can convey a lot of information to future readers of the code about intent, about parts of the code the author regarded as shortcuts and maybe a pointer on how to shore them up, about likely shortcomings or gotchas, and so on. Unless you just allow TODO-like comments to remain but without literally having "TODO" in them, which is silly.
thdrdt 7y ago
#1 is also great for agile projects where you know things can be made better but there are no resources in the current sprint. It also help colleagues to discover why you didn't implement things optimally. So they know you were not lazy but responsible.
spockz 7y ago
Fully agree on the workflow impact. What I usually do is: 1. Write the synopsis of the todo in the code 2. On creation of the MR/PR start discussions on each todo. 3. For each todo which has no quick fix or obvious solution a new issue is created referring to the todo. This way I get to stay in the flow and record it in a big tracker for further discussion.
arcticbull 7y ago
TODOs are fine but only if you also have associated cross linked tickets in your bug tracker. You shouldn’t ever commit TODOs in your code without a ticket number or exactly this will happen.
- MiracleUser 7y ago
  I wonder if there are any tools to create tickets from TODO's
  - Xophmeister 7y ago
    I used to have a pre-push hook, I think, that would cancel the push if there were any TODOs or FIXMEs in the codebase, displaying them out nicely, with their location. I ultimately turned it off :P
- SlowRobotAhead 7y ago
  I think you are ignoring all OP’s points about short term memory and not getting side tracked on optimizations. The latter of which gets me all the time. So you would recommend instead of moving a long he drops what he’s doing and go link the ticket number back into code just to leave a TODO that in high likelihood is him working on eventually or not anyhow? Weird flow but ok.
  - yoz-y 7y ago
    Just do it after you finish and before you send your code for review. Just don’t merge dangling TODOs
    - arcticbull 7y ago
      Exactly by all means have them in your working branches but track them before they hit master
boomlinde 7y ago
There is alway conceptual TODO at a given stage of development, whether you spell it out or not. If you develop "depth first", these are few and mostly transient, and there is no real benefit to spelling them out. You work through the details before continuing. If you instead program "breadth first" you will ignore many details for the time being and instead queue them up for a future look, and tools like post-its, TODO comments, task management tools become really helpful. My main gripe with TODO is that they're comments. Comments don't age well. Sometimes they're not written well. I'm sure that a lot of the 3000 TODOs in the Linux kernel are either things that are already done or things that are no longer considered goals. Some of them are surely hard to figure out by now. Personally I only commit a TODO comment in some limited circumstances. Most of the time I make sure that there are not TODO left before I commit. The ones that may be left at the time I want to commit are great candidates for tasks on an agile board or new user stories.
- mcv 7y ago
  Ideally, every TODO should quickly result in an item on your issue tracking system. The item should point to the TODO in the code so it's easily found. That makes it easy to clean it up once it's not necessary anymore.
- fennecfoxen 7y ago
  In routine application development (which, to be fair, is a slightly different problem than a kernel,) TODO comments are probably at their best when identifying code deficiencies that you don't actually have plans to fix, pointing out refactoring opportunities, and documenting other hacks. If you put this sort of a thing in a bug tracker or other system, no one will see it when they browse the code. (On the other hand, the bug tracking system is definitely the place to put things which should actually get done.)
hinkley 7y ago
I try to remove the TODO’s before I commit, or at least before I push changes to master. It’s always useful to look at your diffs one last time before adding them to the commit history. Most of the TODOs I leave are a form of late code review. There’s some sketchy code at the periphery of what I’m working on and I don’t have the time, budget, or inclination to tackle that problem too. If memory serves, usually for code that won’t respond to a simple refactor. For instance code with complex tests that have locked in the wrong outcomes. Write more two line unit tests, children.
m463 7y ago
That seems very nice, as long as you remember XXX FIXME comes first.

pg_is_a_butt 7y ago

// TODO!! care.

TeMPOraL 7y ago

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 7y ago
> 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
- TeMPOraL 7y ago
  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).
  - simias 7y ago
    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 beyond that I agree completely, `git blame` is not the right way to track the authorship of annotations in a file.
    - TeMPOraL 7y ago
      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.
- daemin 7y ago
  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.

rypskar 7y ago

I use a macro to create an unit test for reason 1 and 2 and name tests with what to test_conditions_expectedResult and add assertTrue(false) as body. I forget to check for todos before I commit, but a failing test is harder to miss

psalz 7y ago

Great points, especially 1 - 3. For me it is also often not so much about optimizations, but rather additional use/edge cases that might need consideration, but I'm not sure yet because I haven't e.g. fully fleshed out an interface yet. Often times I will ultimately just delete the note (going back to your third point), but other times it might result in an additional test case, for example. Whenever I'm starting out on a new project (which might just be a new module in an existing code base) my mind tends to bombard me with these hypotheticals, so it is tremendously relaxing to just whip up a quick note and know that it will be dealt with by future me :). To actually enforce this, for the past couple of years I've been using NOCOMMIT comments, together with a git hook that actually prevents me from committing those lines. I rely on this workflow so much now that I can't even imagine going back. I also get really nervous in pair-programming scenarios when someone will say "Yeah, I'll change/fix/adjust that later" - all I'm thinking is "but will you remember?!".

ahartmetz 7y ago
Instead of NOCOMMIT, I keep the "is it final" bit in short-term memory (maybe helped by reviewing staged changes) and start the commit message with "WIP:" if necessary. It's a convention from the Qt project that its CI understands. The advantage is that it doesn't block other work until resolved. Sometimes what's missing is even a good/better commit message, which is awkward to remark in the code.
jmiserez 7y ago
Yes, automatic enforcement is invaluable. Instead of a commit hook you can also use a pre-receive hook on the server. This allows rebasing, wip commits etc. locally and doesn't require any client config.

jordanbeiber 7y ago

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 points above actually looks like an issue tracker to me. When I find todos I tend to cut them and paste them as issues trough slack bot integration. It keeps an ok flow, although I get annoyed that my fellows could not be bothered... To each their own I guess, and whatever works! Edit: I love in-line comments and documentation though. Just not todos. :)

hashhar 7y ago
RedHat has some tooling that defines a basic format for Todo comments and can be converted to JIRA issues on their Jboss.
- jordanbeiber 7y ago
  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!

stinos 7y ago

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.

heavenlyblue 7y ago
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
- dev_tty01 7y ago
  Too much typing. Try FUDO.
  - heavenlyblue 7y ago
    This is more of a bikeshedding question, but I’d go with NOTE instead.
foobarian 7y ago
One of the more entertaining activities at work is to make fun of ancient TODO comments in our giant codebase. There are some all-stars most of us know by heart such that they made it into the internal company jargon. Tl;dr we ask to resolve TODOs during code review and don't allow them in now.

ben174 7y ago

Back in my Microsoft development days, I fondly remember Visual Studio automatically adding todo comments to a dedicated little docked window in the corner of the IDE. It was very efficient and would always be in the corner of my eye and I would always circle back to them as a result.

keyP 7y ago
I still use this feature, it comes under the "Task List" window. Adds any "TODO" comments in realtime by default but it's also possible to extend what tokens show up alongside "TODO" [0]. I've added "Hack" or "Perf" for temporary implementations that definitely can be improved but not necessarily critical. [0] https://keyboardp.com/post/40190774577/using-task-list-tokens-in-visual-studio-to-improve https://keyboardp.com/post/40190774577/using-task-list-token...
vbezhenar 7y ago
Intellij Idea has this feature as well. Also it checks for new TODO comments when you commit and warns you about them, so you won't forget to fix if you wanted.
yitchelle 7y ago
It was a while ago since I used Eclipse, but I think it greps all the TODOs in the source code or project workspace, and list them as a list of TODOs :-) for you to work through. Not sure if it still does this but I found it to be a really good feature.
- fian 7y ago
  Eclipse still has this and even better you can define your own tags that are also added to the list view. You can then filter by tag name in the list view. I found this handy when doing large refactorings (e.g. that took multiple weeks or months). I could define a custom TODO for that refactoring for labeling tasks that I knew I would need to resolve before completing the refactor but was not able to tackle immediately. It made it less stressful knowing I would be easily able to find the tasks again and the central list made it efficient to clear them all.

jpswade 7y ago

A todo is fine, only if there’s a way to get it to done. There must be a plan otherwise it’s a pointless comment.

agumonkey 7y ago
How would you call a comment for a potential idea/feature ?
- jpswade 7y ago
  The code isn’t the right forum for feature suggestions and ideas.

johndoe18637 7y ago

At work we made it a policy to allow TODOs to remain until code review. At least there, with the help of a second pair of eyes, they should be resolved, removed or made into an issue. Until now this approach works quite well for us.

fierarul 7y ago
This is a good approach except it breaks the link from the TODO location to the issue. Are you replacing the TODOs with an URL for the issue or something like that? How do you know a file has issues/todos by just looking at the file in your editor/IDE?
- shantly 7y ago
  Yeah, I dislike banning TODO comments from passing through both for the reason that they're so coupled to the code they reside along that turning them into an issue is rarely helpful, at least as I write them, and that they can convey a lot of information to future readers of the code about intent, about parts of the code the author regarded as shortcuts and maybe a pointer on how to shore them up, about likely shortcomings or gotchas, and so on. Unless you just allow TODO-like comments to remain but without literally having "TODO" in them, which is silly.

thdrdt 7y ago

#1 is also great for agile projects where you know things can be made better but there are no resources in the current sprint. It also help colleagues to discover why you didn't implement things optimally. So they know you were not lazy but responsible.

spockz 7y ago

Fully agree on the workflow impact. What I usually do is: 1. Write the synopsis of the todo in the code 2. On creation of the MR/PR start discussions on each todo. 3. For each todo which has no quick fix or obvious solution a new issue is created referring to the todo. This way I get to stay in the flow and record it in a big tracker for further discussion.

arcticbull 7y ago

TODOs are fine but only if you also have associated cross linked tickets in your bug tracker. You shouldn’t ever commit TODOs in your code without a ticket number or exactly this will happen.

MiracleUser 7y ago
I wonder if there are any tools to create tickets from TODO's
- Xophmeister 7y ago
  I used to have a pre-push hook, I think, that would cancel the push if there were any TODOs or FIXMEs in the codebase, displaying them out nicely, with their location. I ultimately turned it off :P
SlowRobotAhead 7y ago
I think you are ignoring all OP’s points about short term memory and not getting side tracked on optimizations. The latter of which gets me all the time. So you would recommend instead of moving a long he drops what he’s doing and go link the ticket number back into code just to leave a TODO that in high likelihood is him working on eventually or not anyhow? Weird flow but ok.
- yoz-y 7y ago
  Just do it after you finish and before you send your code for review. Just don’t merge dangling TODOs
  - arcticbull 7y ago
    Exactly by all means have them in your working branches but track them before they hit master

boomlinde 7y ago

There is alway conceptual TODO at a given stage of development, whether you spell it out or not. If you develop "depth first", these are few and mostly transient, and there is no real benefit to spelling them out. You work through the details before continuing. If you instead program "breadth first" you will ignore many details for the time being and instead queue them up for a future look, and tools like post-its, TODO comments, task management tools become really helpful. My main gripe with TODO is that they're comments. Comments don't age well. Sometimes they're not written well. I'm sure that a lot of the 3000 TODOs in the Linux kernel are either things that are already done or things that are no longer considered goals. Some of them are surely hard to figure out by now. Personally I only commit a TODO comment in some limited circumstances. Most of the time I make sure that there are not TODO left before I commit. The ones that may be left at the time I want to commit are great candidates for tasks on an agile board or new user stories.

mcv 7y ago
Ideally, every TODO should quickly result in an item on your issue tracking system. The item should point to the TODO in the code so it's easily found. That makes it easy to clean it up once it's not necessary anymore.
fennecfoxen 7y ago
In routine application development (which, to be fair, is a slightly different problem than a kernel,) TODO comments are probably at their best when identifying code deficiencies that you don't actually have plans to fix, pointing out refactoring opportunities, and documenting other hacks. If you put this sort of a thing in a bug tracker or other system, no one will see it when they browse the code. (On the other hand, the bug tracking system is definitely the place to put things which should actually get done.)

hinkley 7y ago

I try to remove the TODO’s before I commit, or at least before I push changes to master. It’s always useful to look at your diffs one last time before adding them to the commit history. Most of the TODOs I leave are a form of late code review. There’s some sketchy code at the periphery of what I’m working on and I don’t have the time, budget, or inclination to tackle that problem too. If memory serves, usually for code that won’t respond to a simple refactor. For instance code with complex tests that have locked in the wrong outcomes. Write more two line unit tests, children.

m463 7y ago

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