31–40 of 42 posts
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.
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.
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…
Earlier quoted context omitted.
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.
I just enjoy the simplicity of `echo 'remember to test the milk' >> foo/.todo`.
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
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.
Good suggestion! I have noted it: https://github.com/andyw8/do_by/issues/2
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…
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.
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.
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`.