
Auto-expiring TODO notes in Ruby - andywaite
https://github.com/andyw8/do_by
======
tekacs
Might it not make sense to invert the parity of the environment variable and
require its being set for do_by to be used? I imagine most would rather set an
environment variable in their dev environment than ensure it gets set in every
possible production instance... :/

As much as 'turning off asserts' is the classical style, that's more to do
with the design of older instrumentation than the sanity of it.

~~~
andywaite
Good suggestion! I have noted it:
[https://github.com/andyw8/do_by/issues/2](https://github.com/andyw8/do_by/issues/2)

~~~
andywaite
And it's now implemented thanks to joallard.

------
skrebbel
Lovely language / solution mismatch.

Any compiled language would fit this much better - fail at compile time. Or in
interpreted-o-world, at least do it at test time.

I guess it's just lovely when deployed, working, test-passing software
suddenly starts failing on a server (all servers at once, globally), because
someone added a TODO a few weeks ago.

~~~
jerf
From the README:

"In your production environment, set DISABLE_DO_BY=1 to disable checks."

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

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

~~~
theforgottenone
I am guilty of this more often than I care to admit. Ooops.

------
froh42
Don't do that.

Some years ago I had the same idea and realized something like that with the
C-Preprocessor in a C++-Codebase.

When did my Todo's expire? AFTER testing, just before a new release. With my
idea of exipiring Todos I created a major pain in the butt for the team.

It would be different if some other "sort of" alarm would be raised when TODOs
proliferate, but a failure in the code is not a good solution. (i.e. hook a
todo checker into your contious build system, let the nightly build raise hell
when there are too many todos - but do not fail the production code.)

------
iirving
So there may not be much awareness so this, but <strike>Ruby</strike> 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...](http://rubyquicktips.com/post/385665023/fixme-todo-and-optimize-
code-comments)

Better to make a # DOBY annotation and modify the rake task to shame if the
date passed. You could also add this metadata to the existing annotations. If
you what to automate the shaming, write a guard gem to watch for these
annotations.

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

~~~
iirving
Thanks Andy, you are correct! The annotations are part of Rails / Rake.

------
kyberias
Silly.

I fail to understand how the developer getting the surprising out-of-context
(with regard to what the developer is currently doing) build failure due to
time-bomb-TODO-comments suddenly is expected to experience an energy burst and
fix the issue right then and there. After all, the developer didn't fix the
issue when the comment was written!

I think this just leads the developer to either a) delete the comment or b)
increase the due date.

~~~
sctb
After reading the title, I actually expected the code would do the opposite:
remove the TODO because nobody found it to be the right time to address it
over the specified period and they probably never will.

~~~
andywaite
Developers often add TODOs for tasks that seem essential at the time, but
later become redundant.

There is also the use case of when you can't do something because you're
dependent on something else, for example you might have a workaround due to a
issue in one of your dependencies. Once that's resolves, you can update to the
newer version of that library, and remove your workaround.

------
peteretep
Better to make it a NOOP and have an automated test that scans for it. Too
much chance of exercising it in production otherwise.

------
dtech
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)

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

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

------
grrowl
I'd see this with more value as a post-commit git hook. After a certain amount
of time (or date specified) it would warn you that TODOs are about to expire,
and either remove them or update the date. That way it can be project-wide and
doesn't require execution.

------
e28eta
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...](http://www.slideshare.net/eanakashima/everything-is-a-
polyfill-33857559)

------
mkal_tsr
Horrible implementation approach. Mixing runtime exceptions with project
management that you're not guaranteed to hit while testing? lol.

A pre-commit hook is the way to go,

* Post-commit: You'll always catch the exception, but you'll be able to commit expired TODOs

* Pre-commit: you'll have to explicitly change the expired TODOs either by removing them (irrelevant TODO, todo became todone through a refactor, etc.), or discussing a better end-date ... but either way, you're forced to address the expired TODO and not run the risk of committing expired TODOs nor not taking a test path that would miss the expired TODO exception

------
ansimionescu
I started doing something much simpler: When working on a project I just
create .todo files anywhere it makes sense. This way I can view, edit, add,
and remove them very easily with simple shell commands.

I just enjoy the simplicity of `echo 'remember to test the milk' >>
foo/.todo`.

~~~
Argorak
I like your example. Especially because milk expires ;).

------
TazeTSchnitzel
Why a function? I hoped it would just parse comments.

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

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

~~~
andywaite
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?

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

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

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

~~~
watwut
I'm sure it is a simple change. The hard part is to find out where exactly
should you do that simple change and how exactly should you do it. If you do
not have experience with related APIs, you will need a day for googling and
reading. Eclipse framework is huge and not all its parts are immediately
understandable.

