The Code Is the To-Do List
executeprogram.com
The Code Is the To-Do List
1–10 of 80 posts
Re: The Code Is the To-Do List
#2I use FIXME comments for this, though my team's project doesn't have esLint set up to error on them, and I don't think the rest of the team would be good with modifying the esLint settings we've used for so long. But I have the TODO Tree extension for VSCode, so I can quickly jump to any FIXME comments when I need to go back to do stuff, and I don't open any PRs until there are no FIXME's left, so it's a self-enforced version of what the blog mentions.
Re: The Code Is the To-Do List
#3How could such a linter rule be enforced with python? does such a linter rule exist here, too?
Re: The Code Is the To-Do List
#4How could such a linter rule be enforced with python? does such a linter rule exist here, too?
This technique is pretty trivial, and thus very generalizable.
When I was at Google as a new grad, I used to put comments with the wrong number of slashes for my internal todos, which would cause the regular linter to pick it up before review. You can piggyback on any such linter rule very easily.
Re: The Code Is the To-Do List
#5I write a whole bunch of //hhh and //hhh1 (and so on) comments for myself and have a pre-commit hook to scan for them.
Re: The Code Is the To-Do List
#6One of my favorite small linters I made on a previous team:
// todo 2022-06-09 something
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 back who wrote a TODO / who put it off / etc. Though we fairly quickly started adding usernames to the comments for who-to-contact.
Sometimes they're just stuff to do "soon", sometimes they're no longer necessary, there are lot of reasons to delay or delete todos. But oh boy did it work. We resolved or removed about 90% of them in 2 months, and the remaining ones quickly got tasks attached and had bigger plans built around them.
Re: The Code Is the To-Do List
#7I have another method where I simply create a commit with nothing but the TODO/FIXME/DELETEME comments where the commit message is same content. I then make sure to delete all of those commits later before creating a pull request. If I forget any of it, it's obvious just by looking at the list of commits.
This fits my workflow because
1) Github and pull requests
2) our normal commit messages start with an emoji (:+1: or :wrench:)
3) there's rarely more than 10 commits per PR so you can't miss it
Re: The Code Is the To-Do List
#8How could such a linter rule be enforced with python? does such a linter rule exist here, too?
This technique is pretty trivial, and thus very generalizable. When I was at Google as a new grad, I used to put comments with the wrong number of slashes for my internal todos, which would cause the regular linter to pick it up before review. You can piggyback on any such linter rule very easily.
My usual was DO NOT SUBMIT which would show up in all red in the editors and code review tools after the woodly-doodly incident (someone changed WD to woodly doodly to test they were seeing their code and accidentally shipped it). It’s easy to teach your tools about a magic phrase like this
Re: The Code Is the To-Do List
#9I had a different approach but only for personal projects. I used Emacs org-capture to do this as a ToDo. It would remember the file, line and I could schedule a date for it. I used to plan my days using org-agenda and the TODO would show up as a task for the date on which I scheduled it. It would also gather information from emails and other things so on the overall, it was a workable system. No syncing to the outside world and stuff like that though. Also, not very usable in a collaborative environment. Worked very well for personal projects though.
Re: The Code Is the To-Do List
#10This 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?