51–60 of 114 posts
They never get prioritised and very rarely does anyone get to do them.
So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.
Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done. They never get prioritised and very rarely does anyone get to do them. So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.
I'm working on a personal project right now and in order to see how things look, if they work etc, I've got a bunch of vanilla js frontend code and //TODO in a few places to call an API and get actual data. It works great for now as I've hardcoded everything, got it looking broadly like the finished product, and it means that I just have to do the API calls (and programme the API too, of course).
I use them a lot.
Earlier quoted context omitted.
Ignoring the numbers on vertical axis, plots look like they are normalized to fit the plotting area. TODO/LoC should basically have the same form.
I don't think so. These plots are normalized by the max number of TODO's, but that may vastly differ from max TODO/LoC of each project.
Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done. They never get prioritised and very rarely does anyone get to do them. So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.
I dunno... I think they have their place. I'm working on a personal project right now and in order to see how things look, if they work etc, I've got a bunch of vanilla js frontend code and //TODO in a few places to call an API and get actual data. It works great for now as I've hardcoded everything, got it looking broadly like the finished product, and it means that I just have to do the API calls (and programme the…
Not only are you rarely gonna have the time to fix the TODO, but weeks, months, years later when you run into a TODO in your code, you have no idea what the actual requirements were, why it was not implemented, why it hasn't hurt anyone and whether anyone is actually needing it. Thus the TODO comment will remain forever, as you can't figure out what to do about it, without investing a lot of time and energy on requirement engineering.
Personally, I've started to block PRs with TODO comments that aren't directly mentioning the future implementation story/bug. As such, even if the TODO is forgotten in some way, you at least will find a reference point to what should have been done here.
Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done. They never get prioritised and very rarely does anyone get to do them. So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.
That's not the only way to use a TODO, but even if it was, it's still valuable to mark suboptimal code.
Imagine you're investigating a performance bug and see a comment in related code which says "TODO: use a faster sorting method", that's probably going to be helpful.
Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done. They never get prioritised and very rarely does anyone get to do them. So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.
Earlier quoted context omitted.
Sorry to break it to you but these TODOs are a measure of technical dept you've accrued by limiting dev work to issues and stories.
"How noone could have seen how we got hacked (then we checked Git and found a `TODO: Fix Authentication`)"
I wonder what other strings people use like this. So far I have seen FIXME TODO HACK XXX BROKEN.
Earlier quoted context omitted.
Perhaps we should be including a priority in such comments, eg: TODO: high: don't use bogosort Would only be useful if it became a defacto standard though
Back when I used Eclipse there was another level called “FIXME”. Maybe it works in IntelliJ as well.
At least it works in PyCharm, so most likely it works in all IntelliJ based IDEs.
Just today I announced a sweep through all of the TODO's and to either turn them into issues, stories or remove them. Biggest problem in Xcode is that it clogs up the warning list and the real warnings get swamped by them. But it's funny to see that Rust has less outstanding TODO's than our brand new 45KLoC project.
I think it makes sense to get rid of inline TODOs.
On new unshipped projects I've gone down the road many many times where it starts with a TODO comment above a chunk of code and then it turns into a few lines of context or a summary of my thoughts. Then comes linking to references, recapping my thought process on the "why", potentially writing a couple of versions of the code and keeping them commented out, or even having a chat with a friend over IRC and copy / pasting the conversation next to the code.
Now you open a file and suddenly it's your code mixed with a massive brain dump of notes, research and a ton of other things that have no business being in your code base and of course your intent is to remove all of that stuff once you get the well thought out implementation but eventually all of this stuff builds up. Then it happens across multiple files and eventually it becomes really hard to figure out what you need to do.
Putting all of that stuff into a kanban board has been a huge win for me. Now I just drop all of that contextual info into a "research" list and I pick things off that list when I'm ready to really do them.
A made a video about this process a while back at https://youtu.be/HHOkcCqsipE?t=77. It shows an example of the before and the after.