Oh yeah i have not used TODO's much because of this reason this is a great extension will give it a play and see if it makes my life easier then the old checklist ;-)
I strongly recommend *against* doing this. To clarify, if it's just a quick list to organize your thoughts / what you have to do over the next hour, and you intend to delete it afterwards. Ok fine. But in that use case, the "Better Comments" extension is much simpler (easier to config), or even a dedicated TODO.md file that's been added to .gitignore that way there's no risk of polluting the codebase. To specify goal oriented Todo's i.e. the direction you want to take development. What should really be happening is creating issues (on github, gitlab, etc), specifying filenames / line numbers where necessary (and perhaps automating this).
I disagree. It depends on your work flow, but if you aren't committing TODOs, it's a great way to keep track of landmarks and thoughts. If you aren't merging these into staging / main, how is it polluting?
@@syntaxfm Workflow isn't really relevant to the problem? The point is, it's about reducing, mental overhead, and potentially CI/CD overhead. Consider if you are the sole dev working on a project. If you use the extension i.e. have TODO's inline within the code files, then before each commit / merge you have to manually parse and remove the TODO comments. Either that or use the -p option and add files in chunks to avoid committing / merging the TODO's. If you don't use the extension, and have all the TODO's group in a single markdown file, that's better, doesn't pollute the codebase... but then you don't need the extension. Also If you're branching, then for every merge you have to ensure you don't merge the TODO file, either that or try and automate via gitignore / gitattributes. But this also has a shortcoming, if you lose your local copy, you lose your TODO's. Now consider if you are *not*, the sole dev working on a project. If you use the extension, the same overhead applies, only now you have to convey these practices to other devs working on the same codebase. This is also under the assumption all devs will use the proper prefixes for TODO comments so you can automate via CI/CD and strip them out afterwards without affecting actual code comments (e.g. JSdoc/TSdoc). If you don't use the extension, then you have an uncommitted TODO file which others can't see, which needless to say isn't that great for cooperation. --- All of this is mental overhead and overhead for CI/CD that can be avoided by simply doing as i've suggested. TODO's for the mid / long term (shall we call them "non-volatile TODO's"?) do not belong in codebase files, or in a TODO.md file. They belong in issue management of your chosen remote repo service e.g. github, gitlab, etc. This works whether you are the sole dev of a codebase or one of many i.e. you only need to remember 1 mental model / UX flow for CRUD relating to TODO's. Also you don't have to worry about removing TODO's from code / managing them with code at any point (tho of course you may like to close / check off things when they're done in issue managment). It also helps the ol' contribution graph, for people who are into that sort of thing. If you accept this, and TODO's via code comments should not be used. This particular extension (and others like it) should likewise, not be used to encourage the practice. --- Final Note: There is another option. As long as the TODO's are separate from the code yet still able to be backed up / accessed the method would be viable. In which case "second-brain" type software is worth a look. Obsidian if you want a completely separate program to handle TODO's. Dendron VScode Extension if you want to access TODO's within VScode. Both use markdown.
This is a very well-known bad habit for developers. Do not, ever use the code neither the comments to add "todo". They are more appropriated business wise models to follow. Take github as example: You have milestones, you have issues, etc.. you cannot follow a todo if the code separates in branches, etc... So, again: don't ever make TODOs in the comments of the code. This is a bad practice and I'm sad that this is being encouraged in this video.
I strongly disagree with this comment. It depends on your work flow, but if you aren't committing TODOs, it's a great way to keep track of landmarks and thoughts. These are not being recommend to be committed or used to track long term issues. This kind of blanket "it bad" statement in itself is bad. There is nuance to this technique and it's being ignored entirely by comments Iike this. Milestones issues and the like are totally different use cases imo and I don't recommend using todos to replace those techniques. I'm sad that you would villify a valid usecase because of unrelated uses.
I understand what you're saying, but I also disagree. When you're writing a code, having these in comments as reminders is extremely beneficial. Especially if you're spending multiple days writing the same program. Comments themselves should be reserved for, "Hey, this is what this particular part of the code does," while adding a TODO can be a reminder to your train of thought from a previous day, or even as a, "Hey, the program works, but this portion of the code needs attention/add this to the program." After completion, just delete the tag and redocument if needed. Can this be a bad thing? Possibly, if you're working with others and their standards of importance isn't the same as yours. But for a singular programmer or a small group that has agreed upon standards. I colored three of them, along with the better comments extension: Red for bugs (this code breaks the entire program and needs immediate attention), Orange for fixes (the program overall works, but this code doesn't), and Blue for implementation (this is where this function or statement will go when I get to it, but this serves as a reminder incase I forget later). I'm still kind of new to it, but I can see the potential.
❤ Todo Tree! ❤✅🌳
Oh yeah i have not used TODO's much because of this reason this is a great extension will give it a play and see if it makes my life easier then the old checklist ;-)
How to exclude symbols "*@" at end of Razor comments?
Actually you can do everything that Better Comments do with Todo tree
Thanks! Love it 👀
I strongly recommend *against* doing this.
To clarify, if it's just a quick list to organize your thoughts / what you have to do over the next hour, and you intend to delete it afterwards. Ok fine.
But in that use case, the "Better Comments" extension is much simpler (easier to config), or even a dedicated TODO.md file that's been added to .gitignore that way there's no risk of polluting the codebase.
To specify goal oriented Todo's i.e. the direction you want to take development. What should really be happening is creating issues (on github, gitlab, etc), specifying filenames / line numbers where necessary (and perhaps automating this).
I disagree. It depends on your work flow, but if you aren't committing TODOs, it's a great way to keep track of landmarks and thoughts. If you aren't merging these into staging / main, how is it polluting?
@@syntaxfm Workflow isn't really relevant to the problem? The point is, it's about reducing, mental overhead, and potentially CI/CD overhead.
Consider if you are the sole dev working on a project.
If you use the extension i.e. have TODO's inline within the code files, then before each commit / merge you have to manually parse and remove the TODO comments. Either that or use the -p option and add files in chunks to avoid committing / merging the TODO's.
If you don't use the extension, and have all the TODO's group in a single markdown file, that's better, doesn't pollute the codebase... but then you don't need the extension. Also If you're branching, then for every merge you have to ensure you don't merge the TODO file, either that or try and automate via gitignore / gitattributes. But this also has a shortcoming, if you lose your local copy, you lose your TODO's.
Now consider if you are *not*, the sole dev working on a project.
If you use the extension, the same overhead applies, only now you have to convey these practices to other devs working on the same codebase. This is also under the assumption all devs will use the proper prefixes for TODO comments so you can automate via CI/CD and strip them out afterwards without affecting actual code comments (e.g. JSdoc/TSdoc).
If you don't use the extension, then you have an uncommitted TODO file which others can't see, which needless to say isn't that great for cooperation.
---
All of this is mental overhead and overhead for CI/CD that can be avoided by simply doing as i've suggested.
TODO's for the mid / long term (shall we call them "non-volatile TODO's"?) do not belong in codebase files, or in a TODO.md file. They belong in issue management of your chosen remote repo service e.g. github, gitlab, etc.
This works whether you are the sole dev of a codebase or one of many i.e. you only need to remember 1 mental model / UX flow for CRUD relating to TODO's.
Also you don't have to worry about removing TODO's from code / managing them with code at any point (tho of course you may like to close / check off things when they're done in issue managment).
It also helps the ol' contribution graph, for people who are into that sort of thing.
If you accept this, and TODO's via code comments should not be used. This particular extension (and others like it) should likewise, not be used to encourage the practice.
---
Final Note:
There is another option. As long as the TODO's are separate from the code yet still able to be backed up / accessed the method would be viable. In which case "second-brain" type software is worth a look.
Obsidian if you want a completely separate program to handle TODO's. Dendron VScode Extension if you want to access TODO's within VScode.
Both use markdown.
This is a very well-known bad habit for developers. Do not, ever use the code neither the comments to add "todo". They are more appropriated business wise models to follow. Take github as example: You have milestones, you have issues, etc.. you cannot follow a todo if the code separates in branches, etc...
So, again: don't ever make TODOs in the comments of the code. This is a bad practice and I'm sad that this is being encouraged in this video.
I strongly disagree with this comment. It depends on your work flow, but if you aren't committing TODOs, it's a great way to keep track of landmarks and thoughts. These are not being recommend to be committed or used to track long term issues.
This kind of blanket "it bad" statement in itself is bad. There is nuance to this technique and it's being ignored entirely by comments Iike this.
Milestones issues and the like are totally different use cases imo and I don't recommend using todos to replace those techniques.
I'm sad that you would villify a valid usecase because of unrelated uses.
I understand what you're saying, but I also disagree. When you're writing a code, having these in comments as reminders is extremely beneficial. Especially if you're spending multiple days writing the same program. Comments themselves should be reserved for, "Hey, this is what this particular part of the code does," while adding a TODO can be a reminder to your train of thought from a previous day, or even as a, "Hey, the program works, but this portion of the code needs attention/add this to the program." After completion, just delete the tag and redocument if needed.
Can this be a bad thing? Possibly, if you're working with others and their standards of importance isn't the same as yours. But for a singular programmer or a small group that has agreed upon standards. I colored three of them, along with the better comments extension: Red for bugs (this code breaks the entire program and needs immediate attention), Orange for fixes (the program overall works, but this code doesn't), and Blue for implementation (this is where this function or statement will go when I get to it, but this serves as a reminder incase I forget later).
I'm still kind of new to it, but I can see the potential.