When 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 FixmeComment''''''s 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 FixmeComment''''''s 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. -- MichaelFeathers ----- "Reminder" comments can be very helpful. Here are some common examples: * Put "%%%" in a comment. ''(It's something you can search for, with very few false positives.)'' * Put "//TODO: xxx" comments in code. This is a well-supported Java convention. Visual J++ will automatically search out all these "TODO's" and put them on your todo list -- along with compiler warning and error messages. ''So will EclipseIde. Eclipse automatically keeps track of your TODOs, FIXMEs, and XXXs by default, and this behavior can be configured to boot.'' * #needsWork in Smalltalk. Emits no code in most compilers, can be searched for with "senders". * FixmeComment "FIXME" before a dicey piece of code * left-justify temporary code (so that it stands out like a sore thumb), and decorate it with //HACK comments. * Get the compiler to issue a warning if it can, so you (or anyone else) can see it in the build log - #pragma message "Not finished" or equivalent. This is especially useful in situations where you may, for whatever reason, never have time to finish it yourself. At least then someone will see it. * In Java 'throw new Error("Not yet implemented.")' Because it's an error you don't have to declare it and it should never be caught. Though you might need to watch out for certain folks dong dumb stuff like 'catch (Throwable ...)' * In C++, #define a ToBeDoneMacro that throws an exception. * assert(false); or ASSERT(false); depending on your C++ environment. Add a comment suggesting what needs to be done. * Include your reminder, in your comment when you check in the code. Parse the comments on checkin and send an email to a newsgroup ( or bugtrack ). * In Java, use the javadoc @todo tag. * At RonJeffries' suggestion, code a unit test that fails past a certain date. * Or just code a unit test for the functionality in question. If it really needs a FIXME, the failing test will nag at you until you get around to fixing it. Add to the list, and put your name here: JeffGrigg RobCrawford DaveSmith JezHiggins PeterSeibel AndreasKrueger SunirShah AdamBerger LaurentBossavit ''(...to ensure all proper and appropriate payment of royalties. ;-)'' ---- * Create a FIXME macro that creates a do nothing piece of code that generates a warning; The follwing kind of thing works for me on my compiler with my warnings. #define FIXME do{ int FIXME; } while(0) * Or for a more exotic macro. Create a FIXME(NAME) macro that makes a FIXME_NAME warning only on NAMEs machine in debug build mode but makes warnings on any machine in a Release build. Ship No code with FIXMEs. You clearly have not finished yet. If you do ship it and a client complains they are right. * Why do this at all? Because we built the hard bits first to satisfy a minimal feature spec (with gaps) and thus made an unshipabble but runnable prototype that we could show to the clients so we could get real feedback about the problem we were solving. YAGNI defintiely does not apply, all those fixmes about 40 are either going to be needed or at least evaluated carefully to decide that they are not needed. * Why check it in with ToDos. I work in short cycles and some To Dos are outstanding for months. ---- 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 () ---- See NeverDone, ToDo, FixmeComment, DontLoseGoodIdeas