Comments on: What to do about TODOs

by: Paul Gielens

Fri, 25 Mar 2005 22:57:17 +0000

Keep your code clean from todo�s and fixme�s. If the code isn�t worth to improve on the spot, then why bother wasting precious time commenting (and hoping your comment is readable for other humans) instead of fixing whatever needs to be fixed. At least take the time to check or write a unit test to prove your finding.

Steve Currency:
�Before a release, you make sure there are no more TODO�s in the code. Eclipse gives you a list.???

What company you work for? This sounds as the ideal world to me, most of us mark �release??? as crunch time and squashing bugs has priority over todo�s at our house.

Marc Logemann:
You should get yourself a copy of Resharper and (just for fun) run through your code. You�ll be surprised Seriously if you need fragments of code to �test something out??? you have no clue what your doing in the first place. To give an example: Recently I removed about 30% of unused/obsolete code in our project because one of my colleagues used the same (I�ll get that later) approach.

by: Michael Slattery

Tue, 22 Mar 2005 19:05:20 +0000

I agree. TODO’s are litter. I use them a lot, but I remove them BEFORE CHECKIN. If you need them there longer than that you should record them in a tracking system (like Bugzilla). Put code blocks you would have commented out into the tracking system.

The goal you achieve: organization of your thoughts and your code.

by: Arjen

Tue, 22 Mar 2005 16:21:46 +0000

Anonymous, I have worked on big systems, and I prefer to do them in an XP-fashion. This means that I’m constantly adding features (stories) that the customer requested. Even though these features change stuff accross all layers, I commit them as a whole. Thus, the system as a whole is always in a workable state, and doesn’t require reminders. If it does, I use a external system, such as JIRA.

by: Roland Chan

Tue, 22 Mar 2005 15:58:17 +0000

I have to agree with the poster. You should be checking in regularly code that is doing exactly what it is supposed to do. Not what you’re hoping it should do or planning on it to do.

If you’re tempted to write a TODO and practice unit testing or better yet TDD, then your better off writing a failing test. This is better than any ambiguous documentation that might unknowingly be misinterpreted by your colleagues.

This is perfectly valid for the algorithm improvements the previous commentor made. If I can think of some measurable way to improve the algorithm and write it down in the form of a javadoc, then I’m probably well equipped enough to write a unit test for it.

If I’m completely stumped on the requirement then I’ll flag the use case or user story for follow up, or raise this as a risk to be reviewed during the project steering process.

I blogged about this too last month: http://www.thechanfam.net/wordpress/?p=24

by: Marc Logemann

Mon, 21 Mar 2005 23:51:56 +0000

Have to completely disagree on your post. First of all, TODOs are not about bugs, its about things you can do better but dont have the time or the skill to do now. Think about a sorting algorithm which basically works but could be faster somehow. This is a perfect place for a TODO, of course you should allways use a bug/defect tracking tool to further express that you need to work on that sometime.

Comenting out blocks is also perfectly valid for scenarios where you want to test something but dont want to remove an alternative way of doing things. You can argue that in a versioned world, you can retrieve the old stuff anyway, this is true, but sometimes its easier to leave this in the code for some beta releases or whatsoever. Later on you should indeed remove it completely.

But when reading other peoples code, seeing this kind of stuff is definitely one of the smallest anoyances i can imagine.

by: Anonymous

Mon, 21 Mar 2005 23:45:45 +0000

I guess you haven’t ever worked on big systems. When building a use case, you often run into issues that can’t be resolved immediately. You might need a meeting or you might be waiting for information. This is what TODO’s are for. They tell you the code isn’t finished, but it is finished enough to check in.

Before a release, you make sure there are no more TODO’s in the code. Eclipse gives you a list.

by: Steve Currency

Mon, 21 Mar 2005 23:24:06 +0000

Lingering TODO is indeed a problem, but not huge. I personally use TODOs but as a milestone approaches, we make sure that all TODOs are moved to a more appropriate forum like Bugzilla.

TODOs are then great for putting in as you go to make sure you don’t forget anything later. You then just have to have the disipline to grep for them and take care of them when appropriate. That means before you commit or before release.