How to avoid trashing what you've already written?

[Kimchi]

I'm probably putting my foot in my mouth here, but I figured I'd get you guys(es?) opinion on this sort of thing. I've been trying to get a basic bare-bones roguelike going on for almost a month now, and I've learned a great deal about programming by doing this. However, whenever I try to extend something that's i've already coded, I just look at it and think,

"my god, what a load of claptrap."

and then I end up deleting the whole thing to start over with newer, nicer, shinier code. Granted, I usually do end up with newer and nicer code, but I don't actually progress towards making an actual game. I suspect that at some point I'm just going to have to put my foot down and solder on, but I thought I might hear how you guys deal with the "reboot itch," so to speak?

[BtS]

I will tell you one thing. The urge for rewriting won't stop no matter how experienced you are... If you're completely new, maybe it's a good way to start over, but later you have to resist the urge when it grows as fast as the game.

As for a solution to the problem: I usually think that I will finish this and make a new game (with better code) later.

[Trystan]

Code is rewritten more than it is written. Rewrites mean you're learning. That's the way it is.

You can make it easier by breaking things into smaller and more self-contained pieces. That way when you do a rewrite, it's a much smaller piece. You can also make it easier by making sure your code only interacts with a few things at a time. That way you have fewer entanglements you need to take apart. Read up on cohesion, coupling, and refactoring. Keep coding. It takes a long time.

I often leave my code a little messy and then begin each coding session my cleaning something up. That way I'm always moving forward and not leaving too much of a mess.

[Kimchi]

I see. Well, I guess the only thing to do then is to keep putting one foot in front of another. I do like your "clean up a bit each time" approach, though, Trystan. I might try to apply that. Thanks for replying as well, Bts.

[Bear]

There are, to a first approximation, two things that can happen when we design a program.

We might succeed. 

Or we might learn something. 

I don't claim that there are no mixed results, but pretty much everything that can happen is somewhere between those two. 

Either way, you have some benefit and you need to be sure that you take advantage of it. 

If you succeed, the benefit is obvious.  If you learn something, maybe not so obvious, unless you really make an effort to be sure exactly what it is you learned and fix it in your mind so you don't have to repeat that particular lesson again later.

To avoid wasting your time and effort with a learning experience, you have to sit down with the 'load of claptrap' as you call it, understand exactly what the problem was that you got into where you couldn't make any more progress on it, and try to figure out what features of the design led specifically to that problem.  Extract your lesson.  Understand what you did wrong.  Then write it down.  Seriously, if you're doing something insanely complicated you might learn a dozen or more lessons before you succeed (and maybe one of them will be 'keep it simple'), so you want to be able to review all of them, not just the most recent, when you sit down to design again. Each time you start over, review so you know what to NOT do.  Even if you have a lot of learning experiences in your path to success, that is the way to get make progress and eventually get there.

Don't feel too bad about it; this is a basic process that everybody goes through as they learn to design software.  Even pros.  Your first few designs will always be you learning about software design; your next few designs are you learning about the particular problem space; and after that you are ready for the success. 

Just remember that there is no such thing as wasted design effort unless you refuse to learn; if you haven't closed your mind, there are only designs you learn from and designs you succeed with. 

Good luck!

[Omnivore]

As soon as you start getting some pieces you want to keep, be sure to use a version control system like Git or Mercurial.   Commit changes.  That way if you replace something that you later decide you need to keep, you can recover it.

[guest509]

It's all part of the learning curve man! As you get better and better things will smooth out. Listen to the old pros about splitting things into chunks that you can fiddle with. Dunno how far you are into it, but the basic idea is that certain chunks take several input variables and return several output variables.

So then you can screw around with the internals of that chunk, as long as the ins and outs remain the same. You probably know this, but them's the basics of making code that will hold up in a larger project.

If you are like me and generally only do a game or two a year, small ones, you can do the quick and dirty spaghetti. But for anything over a month you need to keep a solid structure, which it seems like you are learning to do.

[Aukustus]

I'm happy with my code if it does what I want. Usually it's ugly but I think it can be rewritten later so I stick with it.

[Cfyz]

There is a fairly well-known article that fits the discussion: Things You Should Never Do, Part I.

[Pickledtezcat]

If you keep everything modular it shouldn't be a problem to go back and change or upgrade a module you're not happy with. I'm not really a programmer so I don't get the urge to clean my code like some people do. I don't care if it's elegant as long as it's bug free and interfaces easily with the other modules.

however I do often get the urge to change something that isn't fun or looks bad. Right now I'm rewriting my dungeon generation and tile display code. I don't know for sure the result will be better so I'm making a series of demos to test the various elements first. Some problems have already cropped up but I've also solved some issues the old system had.

[quixotic]

Just did this :-P Code looks alright, but suddenly fed up with a library and using others/writing it myself. I keep copies of any deleted code though, obviously.

As an amateur I think it's part of the learning process. With other applications, I ask OTHER people if something needs deleting. Can't really assume a lack of bias as the original creator.

[CaptainKraft]

A good way that I have found to curb this problem is to force yourself to continue until you have finished a big milestone. If you must go back and refactor at that point, do so, but keep it short and sweet if possible. Then move on to your next milestone before you do any refactoring. Maybe if you write enough code, you'll look at it and think "that looks like crap, but that's way too much to refactor right now"