   Gamer's Guilt -- Forgetting your Code?
  I am suffering from Gamer's guilt.I spent a month writing a bunch of cool classes and now that they are working and I am moving on to a new phase of my project I find that there are 50 things I wish I had done differently with my code. :(This is new to me since I am working on my 1st "Big" project where I actually have to have abstraction for my classes to keep my code readable.  But I find myself desperately wanting to go rewrite the code that I have.  The code I have is functional, but there comes a point where you have to stop screwing with your code and move on and use your code.  Sort of like when an author of a novel has to stop revising and has to publish the work or move on to other chapters.How do you guys know when to quit screwing with your code?  Ie.  You have finished your map class and now you are moving on to putting things on the map.  What do you use to determine if its time to stop messing with the map?   
  My strategy is to only rewrite something when it is necessary to support new functionality that I want or to fix a bug.   ;Quote:Original post by StoryyellerMy strategy is to only rewrite something when it is necessary to support new functionality that I want or to fix a bug.I am being forced to take a similar approach. Must fight the OCD to rewrite my code... must fight it!  One rewrite I did was for performance but I had to quit after that.;  In all honesty this is where I find that a Test Driven Development pattern really excels and is why I use one.  It helps to keep you from constantly modifying that code you want to use and keeps you from breaking it when you get it to work.Here is the pattern I follow your issue is around point 4.Ok so lets say I want to implement a date class that handles dates.  This is what I would do.1. Requirements:What does my date class need to do. (Relay back a properly formatted and valid date.2. The Unit Tests: Write my unit tests to that requirement.3. Implementation:My unit tests fail so now implement the date class till these pass.  Once they all pass I am done it needs no more functionality at this point.  My tests pass so it does what it has to do no more no less.4. Refactor:Ok how can I make this code more usable and user friendly.  Or even how can I implement this more efficiently.  Remove all redundant pieces etc...5. Run Tests:Make sure our tests pass after making our changes.  If our tests fail don't modify the tests you messed something up during refactoring now fix it.By going through these steps for as much code as possible; I find I end up with more user friendly code that is much more efficient and bug free.This is not for everybody but I think in this situation it could help you out quite a bit with your current issue.   ;  That doesn't really work for me, because I have no real design decided on ahead of time.Instead I had functionality as needed and periodically refactor when I notice that I'm duplicating a certain piece of code a lot and can think of a way to avoid this.   ;Quote:Original post by rattyboyHow do you guys know when to quit screwing with your code?  Ie.  You have finished your map class and now you are moving on to putting things on the map.  What do you use to determine if its time to stop messing with the map?When you can actually put stuff on the map (and generally use it) without grief.;  I never (or atleast try very hard not to) write code until I need it. I really do like TDD's way of forcing you to write the API first, then write the code. That, IMHO, is the best way to write code.   ;  Behavior Driven Development helps fight code creep.I use a tool called 'cucumber' in Ruby that allows me to write my test cases as User Stories.  So basically, I write how I want the code to be used, then I implement it until the test stops failing.This way, I only implement the things that I know will be used.   ;  I've had this feeling before. I made a whole class structure that it turned out didn't make sense and I couldn't implement the spec without copy & paste because it didn't agree with the way multiple inheritence is done in Java.It was ugly and I felt pretty dumb, but I just used copy & paste and finished it so I could move on and do it better next time.   ;  Before actually rewriting that code, try using it first (that is, build some code that uses it). If that quickly becomes hard and messy, then restructuring (not just blindly rewriting) it to a more usable design is beneficial. But if it's only the internal code that's messy, then don't bother tweaking the implementation until you have to (for performance or bug-fix purposes). After all, there are more important things that you can spend your time on, right?Then again, for quick 'n dirty scripts, clean code isn't all that important - get the job done, quickly, and be done with it - and write better code next time. Cleaning up such code often isn't worth the time investment because you're not going to have to maintain that code in the long run.   