The Code Is the To-Do List • Hacker News Board

Re: The Code Is the To-Do List

#31

Post by Groxx » Fri, May 20, 2022, 8:08 AM UTC

singularity2001 wrote: post #29

Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. 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 b…

isn't tracking date and username provided by git (blame)?

The authoring date is, yes. But not the "remind me at" date.

As for author: yes definitely. And it's a great fallback option. But it's not visible in most code review UIs, and even when it is it tends to be the most recent editor, not the author. Git's CLI makes the full history of a line pretty easy to read with -L (usually, depending on if it detects a move or not), but have you ever tried to do that on GitHub? Back through several versions? It's a freaking nightmare, and nobody will try to do that while reading a diff.

Re: The Code Is the To-Do List

#32

Post by shikoba » Fri, May 20, 2022, 8:15 AM UTC

Groxx wrote: post #25

shikoba wrote: post #23

Earlier quoted context omitted.

> Every TODO needed a date A todo is a todo. I don't see why a date is necessary.

It was just to ensure it wasn't forgotten. If it's "long term", stick it for a year out or something, it's fine. Truly timeless? Year 2999 works pretty well, or just don't use "todo" because it apparently isn't gonna happen. We fairly often used it for stuff like "X should be upgraded to fix Y by now, see if this hack is still necessary". If was not, just push it out and check again then. Or do whatever else might be…

You can grep for todo in your codebase. It will list them.

Re: The Code Is the To-Do List

#33

Post by arinlen » Fri, May 20, 2022, 8:40 AM UTC

Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. 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 b…

> 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.

That sounds like an awful strategy, one that needlessly creates problems and revision history noise and team distractions.

Is it awful if a comment leads your CICD pipeline to break? Now imagine having your CICD pipeline break because of a TODO item.

Just create a ticket in your ticket queue and get rid of that TODO.

Re: The Code Is the To-Do List

#34

Post by arinlen » Fri, May 20, 2022, 8:42 AM UTC

shikoba wrote: post #23

Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. 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 b…

> Every TODO needed a date A todo is a todo. I don't see why a date is necessary.

> A todo is a todo. I don't see why a date is necessary.

Indeed a date in a TODO is irrelevant, and more importantly revision control systems already track the date when the TODO was added and updated.

Re: The Code Is the To-Do List

#35

Post by arinlen » Fri, May 20, 2022, 8:43 AM UTC

Groxx wrote: post #25

shikoba wrote: post #23

Earlier quoted context omitted.

> Every TODO needed a date A todo is a todo. I don't see why a date is necessary.

It was just to ensure it wasn't forgotten. If it's "long term", stick it for a year out or something, it's fine. Truly timeless? Year 2999 works pretty well, or just don't use "todo" because it apparently isn't gonna happen. We fairly often used it for stuff like "X should be upgraded to fix Y by now, see if this hack is still necessary". If was not, just push it out and check again then. Or do whatever else might be…

> It was just to ensure it wasn't forgotten.

Why don't you just add a ticket in a ticket backlog, then?

Re: The Code Is the To-Do List

#36

Post by arinlen » Fri, May 20, 2022, 8:50 AM UTC

erung88 wrote: post #26

I used to create a lot of TODOs in the code to track things but some developers just do not prefer this way. My team later switches to more formal project management tools to keep track of TODOs and other tasks (e.g. follow up with clients, etc) and this seems to work better for us.

> I used to create a lot of TODOs in the code to track things but some developers just do not prefer this way.

Requiring TODO items to be created and tracked in an issue tracking system instead of sprinkling comments in source code is a no-brainer, quite honestly.

Issue/bug tracking systems were explicitly created to help teams track pending work. It makes no sense at all to misuse code comments to do the exact same job that's already done by any ticketing system.

Complaining that TODO/FIXIT comments are forgotten when any team workflow is based on constantly reviewing pending tickets and assigning them to team members is something that's hard, if not outright impossible, to justify.

Re: The Code Is the To-Do List

#37

Post by bottled_poe » Fri, May 20, 2022, 9:08 AM UTC

arinlen wrote: post #33

Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. 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 b…

> 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. That sounds like an awful strategy, one that needlessly creates problems and revision history noise and team distractions. Is it awful if a comment leads your CICD pipeline to break? Now imagine having you…

You could have the best of both worlds by making the CI job search the backlog for overdue critical tasks.

Re: The Code Is the To-Do List

#38

Post by srer » Fri, May 20, 2022, 9:16 AM UTC

arinlen wrote: post #33

Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. 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 b…

> 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. That sounds like an awful strategy, one that needlessly creates problems and revision history noise and team distractions. Is it awful if a comment leads your CICD pipeline to break? Now imagine having you…

I do that, create the ticket.

I want to believe it means one day we will do that TODO, it'll beat the priority of all the other tickets in the queue.

But it never does, there's always some critical new feature sales wants, or something bigger on fire.

I still create the tickets, as a kind of cathartic process, a confession to the jira gods, I have sinned and half assed something. Please take this ticket as my penance.

Re: The Code Is the To-Do List

#39

Post by andix » Fri, May 20, 2022, 9:28 AM UTC

My stack has sth like that on by default. It uses the common words: TODO, FIXME, BUG.

I can’t merge a pull request, if there is one new todo added.

And also my IDE (jetbrains) shows me a warning, when I want to commit/push code with new todos. And it has a tool window that lists them.

Re: The Code Is the To-Do List

#40

Post by jillesvangurp » Fri, May 20, 2022, 9:43 AM UTC

Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. 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 b…

It would be a cool little side project to automatically track TODO's and FIXMEs with an issue tracker. There is a lot of monkey work involved with issue tracking currently and a lot of work that isn't tracked or poorly tracked because of it. Lowering the barrier to make work and tasks more visible is useful.