3 ms·
I think this is a really interesting project, thought-wise. It fills in the other extreme for how important a TODO is. A code comment will certainly be forgotte
by nighthawk454 5y ago
I think this is a really interesting project, thought-wise. It fills in the other extreme for how important a TODO is. A code comment will certainly be forgotten, but spontaneous build failures are pretty much maximally not-ignorable.
It's almost like an assert for the environment. Maybe in the same vein they should be compiled-out for production builds? (I see in the docs they can be disabled with a flag.) But of course, if builds don't work, then people won't use it or will turn it off, like asserts.
In particular, this highlights just how much I don't think I would want to use this. Especially for environmental changes like a ticket got closed in some 3p project, or a dependency got updated. Probably the main case is the (hopefully rare) times you have to put in a dirty hack, that you _know_ will stop working at a certain date.
Otherwise, the response seems disproportionate. If it's time-intensive to fix and nothing was actually broken, failing the build is a recipe for getting bypassed. Squeaky wheel gets the grease.
Of course, proportionately motivating you to finish medium-ish term projects with questionable immediate value would solve tech debt in general :P
- solatic 5y ago> In particular, this highlights just how much I don't think I would want to use this. Especially for environmental changes like a ticket got closed in some 3p project, or a dependency got updated. Probably the main case is the (hopefully rare) times you have to put in a dirty hack, that you _know_ will stop working at a certain date. There's nothing that prevents you from commenting out the todo_or_die call that references a GitHub issue and replacing it with a todo_or_die call for next week.
- geon 5y agoI’d just comment it out, but not commit it. The build server should have the disable flag. Merge request with deleted todos without the fix would not be accepted. Commenting out is a slight inconvenience, just enough to make sure it gets done.
- nighthawk454 5y agoThat’s a really neat idea. Being able to specify certain changes as ‘not commitable’ or local only. I often find I have certain changes I always make for development and never want to commit. I always do extra git steps to avoid accidentally including them in a PR. Maybe a .env thing would help.
- Kwantuum 5y agoI can see this being useful when you're maintaining multiple versions and forward-porting patches. Some patches only make sense up to a certain version and you don't want to merge them in the next one up.
- sli 5y agoI just want to say that I love the phrase "maximally not-ignorable," thank you for that.