Plotting the source code “TODO” history of the most popular open source projects • Hacker News Board

Re: Plotting the source code “TODO” history of the most popular open source projects

#111

Post by account42 » Tue, May 18, 2021, 2:49 PM UTC

hinkley wrote: post #108

berkes wrote: post #105

Earlier quoted context omitted.

> but the act of committing their changes (or pushing it to a branch, if you are PR-driven) I'm not sure if I understand you entirely correct, but it seems the "you have to commit" is a large part of the problem. You don't. Your harddrive is not going to crash between tonight and tomorrow. And if it may, and this is crucial, git is not a backup system, so get a proper backup system in place. Commit when you have a co…

> Commit when you have a coherent piece of work done. No, that's the problem. Commit when you are available to deal with the consequences of commit. Having a coherent piece of work reduces, but does not eliminate the chance for problems. If you leave before the code builds, you've created problems for someone else to fix. If you haven't budgeted time for the rollback to go wrong on the first try, you're creating prob…

A commit does not have any consequences. A push may.

Re: Plotting the source code “TODO” history of the most popular open source projects

#112

Post by mgfist » Tue, May 18, 2021, 3:38 PM UTC

jpswade wrote: post #51

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.

Here's my most common use case:

1) Need to do a hotfix on some bug. Fastest fix is to just turn off something.

2) I turn it off (maybe commenting out the line) then add a TODO above it with the ticket number that corresponds to the ticket for turning it back on once the issue has been investigated.

3) Once I start working on the ticket to turn the thing back on, having the todos makes it easy to know exactly what to do (context isn't lost) and I don't end up missing some things because I can just search all of the TODOs.

4) If a TODO is missed, we have a script that will re-open any ticket for which a TODO ticket number is still in the codebase. i.e, let's say we have "TODO: xy-123 ..." If i close xy-123 without deleting that line, the script will re-open the ticket and comment saying that there is a remaining todo

Re: Plotting the source code “TODO” history of the most popular open source projects

#113

Post by eXpl0it3r » Tue, May 18, 2021, 5:51 PM UTC

berkes wrote: post #102

eXpl0it3r wrote: post #54

Earlier quoted context omitted.

On a personal project, I can see this working, on a team project, you're not gaining anything with TODOs, because the chances that you or your colleagues actually go back and fix/implement the TODO are close to zero. 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 imple…

> because the chances that you or your colleagues actually go back and fix/implement the TODO are close to zero. This depends entirely on the team, company and/or work, though. It certainly is not a given. > 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 This depends on the task you are TODO-ing. Su…

It certainly all "depends". My main point is, that if you don't actively plan in to fix your TODOs, then they usually won't be fixed, which you can also kind of see in a lot of the charts where the amount of TODOs just goes up. And as such the question arises whether you really gain anything from them.

I much rather have someone finalize their implementation and create follow up stories/tasks to indicate what needs to be done next, than having hints of what should've/could've been done and nobody ever going back and cleaning those up.

Re: Plotting the source code “TODO” history of the most popular open source projects

#114

Post by mihi » Thu, May 20, 2021, 1:51 PM UTC

nrub wrote: post #91

mihi wrote: post #84

Earlier quoted context omitted.

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.

One option if you're on github, https://github.com/marketplace/actions/todo-to-issue

That is really cool! Thanks for mentioning.