Along these lines, I find a "nocommit" git hook [1] to be an absolute life saver. If for whatever reason I need to temporarily break a piece of code, I just add a `// NOCOMMIT` comment above it, and git won't let me commit if I forget to change it back.
The Code Is the To-Do List
21–30 of 80 posts
Re: The Code Is the To-Do List
#22One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
I had a similar idea a few years ago, but with a git hook. https://jezenthomas.com/using-git-to-manage-todos/
Yeah, a lightly-annoying-when-passed hook would probably be a better fit for smaller environments / personal use. I may have to set that up for my own stuff, thanks!
I set mine up in our CI environment because it was essentially trivial to do so, and it also caught people who didn't have hooks installed... but that's only really relevant because we had a couple dozen engineers rotating between many other projects that religiously avoid hooks. It was far too likely to be forgotten unless it was automated.
Re: The Code Is the To-Do List
#23One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
> Every TODO needed a date
A todo is a todo. I don't see why a date is necessary.
Re: The Code Is the To-Do List
#24One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
I'm going to give this a try. Thanks for throwing the idea out there!
We did eventually add a way to skip it outright per commit fwiw, to avoid merge conflicts when there were a lot of changes flying simultaneously. That may be worth planning on to some degree :) or show a warning if it's within a week or something.
I'll also recommend generally treating it lightheartedly - the person who it interrupts is not usually the person best suited for tackling it. A no-questions-asked "you can always push the date off a bit" policy helped - poke the author of the cryptic comment so they know, and that's the end of the immediate responsibility. Target just enough friction and shared face-palming at forgetting so you don't ignore it outright, like often happens with merely printed lints, but if it becomes annoying it'll be avoided and then it's just yet another Jira competitor.
Re: The Code Is the To-Do List
#25One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
> Every TODO needed a date A todo is a todo. I don't see why a date is necessary.
It was just to ensure it wasn't forgotten. If it's "long term", stick it for a year out or something, it's fine. Truly timeless? Year 2999 works pretty well, or just don't use "todo" because it apparently isn't gonna happen.
We fairly often used it for stuff like "X should be upgraded to fix Y by now, see if this hack is still necessary". If was not, just push it out and check again then. Or do whatever else might be necessary since it didn't meet expectations.
I've encountered many codebases with todos that are years old, sometimes authored by people no longer at the company. A date ensures these aren't lost forever. You can always just push it another year out.
Re: The Code Is the To-Do List
#26I used to create a lot of TODOs in the code to track things but some developers just do not prefer this way.
My team later switches to more formal project management tools to keep track of TODOs and other tasks (e.g. follow up with clients, etc) and this seems to work better for us.
Re: The Code Is the To-Do List
#27One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
My team also dates its todo items by the date of creation.
I have played with the idea of failing building or linting after a specific date, but I have said no. I want to be able to check out a specific commit and have the same experience as when the commit was created. Having the linter fail based on the current computer clock setting would make that impossible.
Re: The Code Is the To-Do List
#28One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
My team also dates its todo items by the date of creation. I have played with the idea of failing building or linting after a specific date, but I have said no. I want to be able to check out a specific commit and have the same experience as when the commit was created. Having the linter fail based on the current computer clock setting would make that impossible.
Definitely agreed, don't tie linting like this to your build system. It'll also suck if it blocks fixing an urgent problem.
Re: The Code Is the To-Do List
#29One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…
isn't tracking date and username provided by git (blame)?
Re: The Code Is the To-Do List
#30This is a great idea. But I would like my eslint to produce a WARNING, not an ERROR when I have a certain keyword in a comment. Like if I wrote FIXME in a comment I would like it to produce and eslint warning which would let the code compile and reload (in create-react-app let's say) but it wouldn't build in CI because it has a warning. Is there a way to do this with eslint?
This is exactly what the article describes. Lint ERRORs that block CI but not compilation.