91–100 of 114 posts
Earlier quoted context omitted.
Or do both. Might as well add TODO: to make it stand out as a thing that can be improved while also making it greppable.
Might also be cool to automatically create these tickets (when commited to master?). Then you don't forget, and even if they end up not that detailed, you at least get a nice list of all of them.
Earlier quoted context omitted.
While it's probably the case for postgres or Django, todos getting less could also mean high code churn.
Yeah I noticed several cases were there to do's drop dramatically. I wondered if that was because that was a module that had a lot of to-dos that was also low quality, and the subject of a complete rewrite or replacement at some point. Golang was also interesting because of a huge increase followed by an almost equally huge decrease a short time later, both of them seemingly vertical. I wonder if something got revert…
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.
TODOS are great documentation. They often reveal design decisions, suboptimal implementations and the thought process of the creator. This information is often completely lost in issues that noone will ever look at again. I also like to do TODO sweeps, but with a bias towards rewriting the into documentation or leaving them in if the are actionable.
"This information is often completely lost in issues" - of course, because an "issue" is "a vital or unsettled matter" and are not meant to be revisited once resolved. Writing design decisions or thought processes in issues seems equally weird to using TODOs to document that. They're kept around because it costs nothing and you might want to refer back to it for details on some past problem, but I've never heard of that being considered documentation.
I always suggest TODO's to be replaced during a Code Review by: 1. A ticket number that will be picked up shortly if should still be part of a larger change. In a healthy team, this is done within two weeks and you know where to perform changes when you pick it up. 2. You do not add a TODO, but explain your current understanding of what is wrong and what should be done. This way you can refresh the knowledge if it ev…
The kind of TODO you're talking about is splitting a ticket into parts so you can hit an artificial deadline (ie, it's no longer 'done done', it's just 'done'). If the artificial deadline is your boss, then we're in a bad place. If it's another team needing a feature, that's pipelining and that's often okay.
For the TODOs that make it to PR without human error, I write most of them for the next person who adds functionality to an area, to either encourage them to do so or at least not make things worse. But sometimes it's for the person who hits the Rule of 3.
Those TODO's should be addressed in six months, not two weeks, and having someone call me on them in a PR is not particularly helpful. No, I'm not going to quadruple the scope of this story because you don't like the word TODO.
Earlier quoted context omitted.
TODO: Automatically create tickets based on TODO comments. We'll get to it. Someday.
https://en.wiktionary.org/wiki/round_tuit There used to be an ASCII art version occasionally slapped on Usenet posts: "here's a round tuit, you can go ahead."
Well, I'm glad I'm not the only one who never gets around to my //TODO#s. One related tip for devs: I've started adding "You are here" as a placemark for where I'm working in the code. So for example, on friday, if I want to pick up quickly next monday, I add "//TODO: YOU ARE HERE Finish doing foo". Then on monday, I search for "You are here" and pick up where I left off easier. Saves me a few cycles, though if I'm h…
I forgot how I went from "Water in the well" to "ink the well", though. It's been a while since I started doing it, and I wrote a blog-post[1] with some scripts and helpers that I still use.
[0] https://www.fastcompany.com/3021905/hemingways-secret-to-mai... [1] https://berk.es/2012/05/30/leave-some-ink-in-the-well/
Interesting that some of them don't grow, or don't grow much, over time. Someone at PostgreSQL and Django is actually reading and fixing the TODOs.
It would also be interesting to plot the number of TODOs against the size of the code base too. One would assume that as a project grows, the number of outstanding TODOs would grow too. Where and when this isn't true, might reveal something more interesting.
I believe that one of the cognitive dissonances with people who think a lot of code is good news is that they become overwhelmed by how much they would actually write if they stuck to their convictions and so they start using TODOs to make themselves feel better about doing the wrong thing.
Projects that grow slower I suspect have fewer TODOs.
I was just thinking the other day that searching for TODO is probably a very good way to search a project for potential bugs or security issues. E.g; I see a bunch of todos in Firebase iOS SDK that look kind of interesting to an attacker. Without looking into how the methods are called I can't say if they are actually exploitable (and I am sure Firebase is fuzzed to high-hell) but it was a little seed planted in my h…
Sometimes the vulnerabilities are just handed to you on a dark-themed platter and I don't look them in the mouth.
Is it controversial to say that those with low TODOs are pretty clearly the cleanest packages I enjoy working with most? (Postgres, Rust, Django, VueJS, maybe Python)
Use and semantics of TODOs are decidedly not consistent across these projects. Just because you (and I) see correlation with our expected biases shouldn't be construed as proof: merely interesting chart wiggles. I think the shape (monotonic increase or sawtooth) can be used to see how a project handles either missing features of technical debt.