I know prom has gone over it before to a degree but I figured I'd ask a specific questions regarding script structure. As I have stated before I am rewriting my coloniser and its going well, however I am trying to truely make it easier for me to read and to eliminate redundant code. Part of my approach is to use Gosub for a majority of smaller actions so I can keep the main code as clean as possible. I am running into difficulties when writing for the different tpes of colonising (macrowise) I really would like to stay away from having to write tons of dif macros.



Mostly because I would have to write so many differnet macros and as I add protections (Tlock,fighit,figloss,limphits,etc) I would more than likely have to rewrite those again.

So heres my questions finally:
-What do you recommend for script structure?
-Do includes work better than subs?
-Am I forced to have a buncha macros for the if structures in a effort to not clutter the main code?

I ask because I believe I'm looking at a significantly large script and the more lines I can save the better, as well as making it easier on the eyes. The original TFarmer was like 600lines long, I expect this one to near on 2-3k when its all said and done.

I think includes make it tougher to follow, but if you plan to reuse that block of code in other scripts... well then yea, use includes. Otherwise, I just use gosubs w/ separation comments thru-out it. 3k lines isn't all that bad, my public ugridder is 1800, and it's all 1 file.



Whatever is easier for you to read, go away from, then come back to and still understand.



Not particularly. Depends on whether you'd find them easier or not.



I wouldn't do it that way at all. You're going to end up with different trigger checks for each macro, so you might as well just make a complete gosub for each. If you want to save lines, then think of common routines within each of those blocks and gosub those as well.



Atleast that's how I'd do it, that way you could add new methods to the script over time by just adding a new gosub and sticking it into the control routines.

That makes sense, I just want to make sure I don't have a block of code like my original TerraFarmer.


Which looks like I basically did the opposite of the gosub and just defined the If right there in the main code. Made for a really messy and hard to read script a year+ later. I think I'm going to use #179(and other acsii) this time around and emulate lonestars method of adding text to my $var to make it more dependable.

I agree with Sing on using whatever makes it easier for you to read. Comments will help a lot when you write something that you "thought" would work, but had to change to get to work. What I am saying is that sometimes you will come back a month or two later and think "why didn't I do it this way" when you might have already tried it. A comment with a reason for the code would help. Now after saying that, proZTM contains less than a dozen comments, and they are usually something like # was <= 1 changed to <= 2. Basically what I ran, and what I changed it to - sometimes including the results of the run for each.

I can think of one for most scripts and that is when you are optimizing for speed: # ran with x option with y loops in ss seconds vs z option with y loops in ss seconds - I can't improve a script unless I have baselines to work with. I go for speed and not necessarily the cleanest (modular) coding method. I've said before, I am not a good scripter, just almost good enough to get by and that is what is important - getting the results you want.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

Script Structure. I favor a top-down approach, letting execution flow down through a routine. I try to use a Modular format for the complicated scripts --for example, my planet creation script almost 2700 lines). I've started to place Startup-code (including menu's), at the bottom of the Script (as a subroutine), with the Main routines above the startup.

For really large Scripts I find that using Inlcudes is MUCH better than Subroutines, not for performace, but for:

• Debugging - Execution Error msg's are much easier to trace and Problem Variables have preappended to them the name of their respective module. You can tell the difference between $STATS~i AND $LIB~i when reviewing Variables ($SV i).
  
• Coding - During I usually leave alot of 'bookmarks' in the file to CTRL-F to for speed, you wouuldn't need to do this as much with Includes. Also having all your Includes loaded (As 'Pages' in Context text editor), saves alot ot time hunting for Code or Copy-Pasting.

Sometimes you are forced to use many Different types of Macro's to perform the same Task. One method i learned from Mind Dagger involves Flow-Charting the task at hand and creating the segments of the task in short maco-strings to be built up later on.


To save someone some of the headaches I suffered, I would suggest delvope you own style. Comment your Code well. esp at the start, and where ever your being 'clever'; using a Trick; during development; or creating a complex routine.