3 ms·
I agree with all except the last; I think "someday" comments are very useful. If behavior is strange, you want to know if it was expected to be that way, and w
by makecheck 16y ago
I agree with all except the last; I think "someday" comments are very useful.
If behavior is strange, you want to know if it was expected to be that way, and why. You can use the developer's line of reasoning to prioritize. If you understand the conditions that brought the hack, you are better prepared to maintain the code.
The article suggests that most problems should just be fixed right away, instead of leaving "someday" comments. But, a few weeks of maintaining a large code base will cure anyone of this belief. Not everything can be fixed right away, for many reasons:
- Maybe there isn't time, due to pressure to complete X or Y.
- Maybe it's risky to just hack in the first solution that pops into your head, and you need time to come up with the right fix.
- Code bases can be very complicated. You're not usually working on your own brilliant creations, you're working on things that many other people did, and some of them had no clue. You are tinkering with an engine you didn't design, and you have to be careful.
- The bug might actually be important in the short-term. One of the evil realities of large code bases is that "bugward-compatibility" can matter, and "fixing" something may cause more immediate problems than it solves.
- barrybe 16y agoI have to agree, I think TODO and FIXME comments are just a fact of life. I haven't seen a large codebase that didn't have them. But, if you write one of those, at least try to be realistic. Too often I find comments saying "XXX THIS MUST BE FIXED IMMEDIATELY!!" in code that hasn't changed for years.
- bradly 16y agoTODO's and FIXME's are a fact of life, but if you are using a bug or issue tracker, that is probably a better place to report these. Otherwise you'll have tasks in both your code and your issue tracker instead of a central location.
- makecheck 16y agoNot necessarily. Yes, if you're fortunate enough to have something like Trac that can easily link between a line of code and a ticket number, then bug reports can handle everything. But otherwise, how would you describe it? Sometimes a problem only "makes sense" if you're looking directly at the affected line of code, and the comment is right there. If you leave a 'grep'-able thing like "FIXME" in your comment, you won't really lose it.
- mahmud 16y agoI worked on an inherited project that had /* FIXME: 8372 */ except we no longer owned the bug database. Really wished the comment actually explained WTF was broken, instead of leaving me perform exhaustive tests with a SOAP sandbox halfway across the world, and a security/performance hack that involved keeping track of a per-request nonce AND a 5s sleep :-/
- jerf 16y agoTODOs and FIXMEs are, at least in my opinion, things that aren't manifesting as bugs right now, but might in the future. Having them in the tracking system will just confuse management and QA. Just put them in the code, which has the advantage of putting the FIXME right next to the thing that needs to be fixed. They've saved me many times, and I've had exactly the situation I describe above occur, so while I sort of am with you in theory, in practice they should go right in the code.
- nitrogen 16y agoEclipse keeps track of TODO and FIXME comments, and can sync them with a bug database.