I have this problem also. My current game is missing a few this just to make it a little sweeter to play. When I look at the code on the screen in the editor I go "What a Mess"

Here is what I am doing:

1 - I printed the whole program out on paper. (easier for me to read)

2 - Started to follow program flow, drawing lines and arrows to where I want to move my Functions and Procedures.

3 - Now I am "Cutting" and "Pasting those blocks and code into a more logical program flow.

It is amazing once I started making relocation lines on how much "Spagehti" code became apparent.

Give it a try. Maybe that might help solve your problem.

What I wanna know, is what you've done to organize the code better. Have you tried refactoring stuff and simplifying things into parameters and whatnot, so as to not have to write the same code over again and so on? I'm definitely not a professional myself, but one of the most important things I've learn from a professional, is how to code placeholders when you only need something basic and then be sure to refactor it later, either by extending upon it or tightening it up (or both).

If you feel like you're digging yourself into a hole, then maybe now's the time to go through your code and reorganize it. Programming a game is almost like micromanaging economy-based games, like SimCity. I constantly think about how I can make everything simpler and more economic, looking at every single detail and tweaking it just a bit, not too much. The further you are into the process (i.e. the more complex it is), the more can go wrong. Especially if you got jumbled up code.

If you're almost finished with your game, finish it and learn from your mistakes. If there's still a long road ahead, take some time to refactor your code so it will save you the time in the long run and you don't have to hack stuff in or do unneeded work-arounds.

So just do it if it is worth the time and effort, this obviously depends on how big the project is now and how big it will be in the end. Also if the performance is going to suffer a lot, it might be a good thing to refactor the bigger parts.

Reformat it and make it look cleaner (indent systematically with statement block delimeters)

Add commenting and visual breaks for obviously grouped code

Move globally initialized data/variable definitions to one file and struct/record definitions to another

Break out chunks of code into subroutines (particularly where they are either called once a game turn pass in the main program or consolidate duplicated code)

make your variable/subroutine names more consitant

Well into the project, I say that you should complete it but in a reduced form from your original goals.

Next time you should build code in modules which can be unplugged and plugged into the source code, sometimes swapping an old module with a rebuilt one. This is a separate issue from libraries which may each contain potentially many modules of coding. The key is to structure your source code so that calls are the actual point of connection between source code and specific modules.

Don't worry because it is usually good practice to complete a project.

Clinton

I must confess, I had performed a cardinal sin of programming. I did not comment my code (save a line here or there).

Code commenting is almost an art of its own, because you definitely want to do it, but not too much either. Often, all you need is the right names for your variables and functions and that'll say all that is needed. But on bigger projects, definitely comment your code to quickly find and understand it. You will forget what you just wrote yourself, if you wrote it three months ago and never wrote it again.

Besides, it's better to write too many comments than too few, IMO.

A few people keep a heavily commented version (the technical name of this version fork alludes me at the moment) which is commented immediately after commenting the code line of the working copy.

Sooner or later you will find the need for version control (source control) and it is much helpful in managing workflow pipeline and later editing or debugging.

Clinton