Forget To Fix It Later
Forget To Fix It LaterWhen I write new code, I have this massive design in my head and I just have to get it all into the machine as quickly as possible, before it leaks out of my ears. In my rush to get the code down, I usually skip exception handling and documentation. If there's some exception I'm forced to handle, I usually print an error message and return a dummy value.
The problem occurs when one or the other of these things I ignored in the rush to get the code down gets left behind and turns out to be important. I don't know how to deal with this, I can't write production code from the beginning of the file to the end of the file, I have to get method declarations in and define interfaces and write the really hard bits of the algorithm.
When I am settled down, I go back and fix MOST of the problems.
-- JohnFarrell
I HaveThisPattern. I make liberal use of FixmeComments to remind myself of things I haven't done. Most of them go away during later parts of the coding session. In combination with the FixmeComment, I also use an assertion or throw an exception to make sure I will notice when I try to execute code I haven't written yet. I usually go back and fill in all those details like error handling, but sometimes we are too busy and neglect that cleanup for a long time. Also, I sometimes end up with a few FixmeComments left over for hard corner cases that I don't know how to handle properly, and those can persist for months or even years. -- WylieGarvin
One way I use to avoid this is to try to explain the plan I have in a bit of documentation (perhaps the ProgrammersNotebook most often) at a level where I think I can read it and understand what I was aiming at. Only then I go ahead with the implementation. And sometimes if a more elusive idea manages to escape, I'll try to comfort myself by thinking that I'll need to understand the problem a bit better still (or divide it before trying to conquer) if the answer was that hard to hold on to.
For more advice see DontLoseGoodIdeas.
There are a couple of things that help me in this situation. One is to write little tests, as I go, in a TestingFramework. Another is to really give up and realize that even if the design leaks out of my ears, I'll end up doing well. If I thought it up once, I can surely do it or something better again.
Giving up in this way helps because then you can take the time to concentrate on one thing at a time. If I do discover something else that I need to do, but I'm in the middle of something else, I leave my initials in little comments in the code. Whenever I think I am done, I search for "MCF" in the code and make sure that I really am done.
"Reminder" comments can be very helpful. Here are some common examples:
(...to ensure all proper and appropriate payment of royalties. ;-)
#define FIXME do{ int FIXME; } while(0)
If you have a massive design in your head, perhaps you are waiting too long to code. See, for example, ToAyoungExtremist for an alternate viewpoint. --RonJeffries
I type too slow! --JohnFarrell
Maybe you're starting to type too late. Let the program evolve while you think, not after. The computer is right - your head may not be.
However, if you really must: write a UnitTest that tests whether the thing you were going to fix doesn't work. Ensure that it doesn't work. Then change the should to succeed until your deadline for fixing it comes:
self should: [Date today < self deadLineToFix or: [self testThingThatDoesntWork]].The test will run OK until the deadline goes by. Then it'll fail and you'll have to fix it. UnitTestAsTickler.
Wow! A "Logic Bomb" as a programming style suggestion. Let's just hope you never mistype a deadline or have to ship early. That would lead to serious egg-on-face. --FrankCarver
It's in the tests, Frank, not in the code. We have all these tests. We run them before every release. If they don't work, we know something has gone wrong BEFORE we ship. It's kind of nifty, actually.
How many times this week have I had someone call in with a problem from one of our test sites, and traced through the code, only to find // TODO in the spot where it fails?
Let's go and burn down the observatory so this will never happen again! - Moe, after Springfield escapes being destroyed by a comet. The TODO comments are not the problem. The problem is not searching for those comments before making a release. -- DanielEarwicker
The TODO comments are the problem. Either do something now or don't but please don't try and do it halfway. Resorting to TODO comments is a sign you are trying to do too much at once. --WayneMack
This reminds me of the TechnicalDebt page. If you manage to keep TODO:s under control they can be good, since they may enable a small temporary advantage. It's just that it's really hard to keep things like that under control. -- AndersBengtsson
Code isn't done if there are TODO's left in the code. Don't check that in. If it is a feature suggestion, put it on the task/To Do list, which is separate from the code. Guaranteed a user is going to stumble on the code and then you're hosed.
If I have to check it in I ASSERT(FALSE); with a detailed comment suggesting what needs to be done. I only do this when someone else needs to fill it in or someone wants part of the system ready before I done with it. I then put the item on the task list with a high priority.
If it's a feature you don't need in this iteration, YouArentGonnaNeedIt, so leave it out. The place is the task list.
-- SunirShah ()
EditText of this page
(last edited February 14, 2007)
or FindPage with title or text search