Auto-expiring TODO notes in Ruby • Hacker News Board

Re: Auto-expiring TODO notes in Ruby

#21

Post by andywaite » Sat, May 17, 2014, 2:51 PM UTC

theforgottenone wrote: post #16

jerf wrote: post #12

Earlier quoted context omitted.

From the README: "In your production environment, set DISABLE_DO_BY=1 to disable checks."

Given that we are talking about lazy/overworked on top of lazy/overworked here, why any confidence that this will be done 100% of the time? Putting time bombs in your code, regardless of a global configuration switch, is just asking for trouble.

You're correct, I'm going to change it to be disabled by default.

Re: Auto-expiring TODO notes in Ruby

#22

Post by andywaite » Sat, May 17, 2014, 2:55 PM UTC

Ruud-v-A wrote: post #18

andywaite wrote: post #15

Earlier quoted context omitted.

I think that's a good idea. Perhaps based on a standard format such as '# TODO 2014-01-01 Fix me' ?

Why put the date in the comment itself? Just ask source control when the line was introduced, and set a max age.

Interesting idea, but I'm not sure if that would be possible for all cases, for example what happens if the part of the line before the comment changed?

Re: Auto-expiring TODO notes in Ruby

#23

Post by middus » Sat, May 17, 2014, 2:58 PM UTC

skrebbel wrote: post #11

y14 wrote: post #2

This is excellent. I always fail to keep track on my TODOS in files. Very useful.

Use a decent editor.

Alternatively, you could continue using your editor of choice for editing and use grep to identify TODOs in your code.

Re: Auto-expiring TODO notes in Ruby

#24

Post by andywaite » Sat, May 17, 2014, 3:05 PM UTC

middus wrote: post #23

skrebbel wrote: post #11

Earlier quoted context omitted.

Use a decent editor.

Alternatively, you could continue using your editor of choice for editing and use grep to identify TODOs in your code.

Yes, if you're disciplined, and remember to do this regularly. But humans aren't perfect.

Re: Auto-expiring TODO notes in Ruby

#25

Post by dbuxton » Sat, May 17, 2014, 3:12 PM UTC

Ruud-v-A wrote: post #18

andywaite wrote: post #15

Earlier quoted context omitted.

I think that's a good idea. Perhaps based on a standard format such as '# TODO 2014-01-01 Fix me' ?

Why put the date in the comment itself? Just ask source control when the line was introduced, and set a max age.

Fantastic idea and what I thought when I saw this post; I'm slightly surprised that nobody has produced a git one-liner to achieve this yet!

Re: Auto-expiring TODO notes in Ruby

#26

Post by andywaite » Sat, May 17, 2014, 3:22 PM UTC

iirving wrote: post #19

So there may not be much awareness so this, but Ruby Rails (as noted below, the annotations or part of rails/rake) has this feature that you can add special annotations # TODO # FIXME # OPTIMIZE comments to you code, and "$ rake notes" to list them. it also allows you to have a custom annotations comments : For a full description, see : http://rubyquicktips.com/post/385665023/fixme-todo-and-optim... Better to make a…

This is a Rails feature, not a Ruby feature. But building something based on this could be useful.

Re: Auto-expiring TODO notes in Ruby

#27

Post by sootzoo » Sat, May 17, 2014, 3:35 PM UTC

theforgottenone wrote: post #17

dtech wrote: post #3

Wouldn't this be much more suitable to do in an IDE or compiler? Raising exceptions during runtime seems the wrong approach to me. I wouldn't be suprised if this is possible and used in e.g. Mylyn. Another idea would be to automatically create a task/bug/issue for every TODO created (which closes when the TODO is removed)

or an IDE that just scans the code files, picks out the lines of comments containing "TODO" and put them in a list in the gui, so you see it all the time. Or generate a compile warning instead of a comment. Then it will annoy you constantly, with no risk to production.

I think he makes the case (and I agree) that if you create a substantial number of TODOs and they manifest as IDE/compile-time warnings, they eventually become noise which you learn to ignore instead of fix.

Re: Auto-expiring TODO notes in Ruby

#28

Post by jerf » Sat, May 17, 2014, 3:53 PM UTC

theforgottenone wrote: post #16

jerf wrote: post #12

Earlier quoted context omitted.

From the README: "In your production environment, set DISABLE_DO_BY=1 to disable checks."

Given that we are talking about lazy/overworked on top of lazy/overworked here, why any confidence that this will be done 100% of the time? Putting time bombs in your code, regardless of a global configuration switch, is just asking for trouble.

I agree with you; my point was that while skrebbel spoke as if the point had never even been considered, it had in fact been considered.

I have to admit to a certain amount of pet-peeve-like sensitivity to people commenting in ways that make it look like they only read the title.

Re: Auto-expiring TODO notes in Ruby

#29

Post by e28eta » Sat, May 17, 2014, 3:56 PM UTC

I like it. It reminds me of a concept [1] I saw presented at Fluent Conf this year, called Sunset Tests. The idea is that when you write code which shouldn't be a permanent addition to the code base (for example, a poly fill for IE 7, or an A/B test), write a test that checks for the existence of that code and fails if it's still there past a certain date.

I wonder if the TODO method could dynamically generate a test case that does the same.

[1] Everything is a Polyfill: Automate Deleting Code for Front End Performance - Rachel Myers and Emily Nakashima

http://www.slideshare.net/eanakashima/everything-is-a-polyfi...

Re: Auto-expiring TODO notes in Ruby

#30

Post by recursive » Sat, May 17, 2014, 4:03 PM UTC

aaronem wrote: post #20

watwut wrote: post #13

Earlier quoted context omitted.

My TODO comments show up in nice view in GUI I use (Eclipse). I'm sure other GUIs have similar views somewhere. I'm also sure that plugin to turn old ones into syntax errors could be done in a day or two. That sound like much safer approach then runtime exception.

A day or two, really? That seems like an awfully long time requirement for what should be a simple change.

If you're experienced making Eclipse plugins, it would probably be under an hour. If you're not, it could take you a day to learn how.