Methods of programming/scripting (Discussion)

[igneous01 19]

I want to start a discussion on peoples views or methods on ways of writing code or making scripts. Particularly when it comes to large projects (ex. UPSMON) and how people organize their code.

The way I have always organized my large scripts is like:

- Constants

- Variables

- Functions

- Procedures

- Execute the actual script

To me personally I have always liked this format because I can easily call upon the same functions or procedures repeatedly without making a mess in the actual script itself (which might be the main loop, etc)

or declaring all my functions and procedures inside a separate script, preprocessing it, then having the actual script be run somewhere else so that it can use these functions.

But ive noticed that other people make a ton of mini scripts that do stuff, and call these scripts inside a main script, which i feel can get really cpu intensive (especially if the main script is dealing with arrays of units/objects and calling these other scripts)

then theres also the scopes, breakTo, breakOut and jumping from one scope to another to repeat the same kind of code. Though im not fond of jumping everywhere in a script, because its a pain to debug afterwards.

So, how do you guys compile and organize your scripts/projects? and maybe offer some pros/cons of the method as well. I hope with this information newer coders/scripters can learn about formatting their scripts so that they are more streamlined and easy to follow.

Discuss :D

[AZCoder 675]

I write Functions and Procedures to be very specific to a task, such as one for deleting in-game objects. That makes it reusable & easier to debug. I compile them when the mission loads. Otherwise I tend to put a bunch of ad-hoc functions into one master script for a given mission that triggers and such can refer to by name, such as this one for when the player gets killed in a mission:

AZC_KIA =
{
enableTeamSwitch false;
playMusic "track21_rise_of_the_fallen";
cutRsc ["KIA", "PLAIN"];
sleep 5;
failMission "KILLED";
forceEnd;
};

I think it's important to avoid what is called "spaghetti code" which you alluded to, as that is very difficult to debug, is more prone to errors, and difficult to modify since it's not always obvious to know where program execution is flowing.

[loyalguard 9]

Most of my projects are intended to be compatible in SP, MP host, and MP dedicated server play...so...the structure of my projects is usually organized along those lines. This usually means multiple scripts that run segregated code necessary for each type of machine running it. Here is the normal structure:

1. A project specific "init" script that is executed from the mission init or an XEH. The purpose of this script is to run code needed by the server and clients such as JIP checks, compatibility checks, loading common functions, adding PVEHs, and launching separate scripts needed for servers and clients.

2. A "server" specific script that runs server only code.

3. A "client" script that runs client specific code.

And if necessary

4. A "common" script for MP hosts and clients (but not dedicated servers).

Usually these scripts in turn load and then call/spawn additional functions or execute additional scripts rather that contain all of the required code inside them alone. I have found this much easier when needing to tweak specific portions. Despite the larger number of seperate scripts and functions, it is still easy to follow "program flow" because I meticuously comment all my code and document how something was executed/called, what parameters were passed to it, and what it in turn execs/calls/returns.

All of my functions reside in seperate .sqf files so if needed by different types of machines or different executing instances they are easily available and changeable. I also try to only load or preprocess a function if I know it will be needed later depending on how the mission evolves and ensure it is only loaded once via an isNil check..

All of my .sqf files are structured the same. A header comment with the name of the .sqf, version, description, what the parameters passed to it are (if applicable) to include type (string, integer, etc) and what exec'ed or called the file. I then immediately set the scope for my local vars and extract any parameters from _this and store them to specific local variables. Only then do I begin commands and control structures.

I also almost always embed developer debugging code (that usually dumps what is going on to the .rpt file via diag_log) throughout the file that only runs if I declare a specific global variable true in the mission's init.sqf while developing/testing. I always leave it in after release in case I have to fix bugs later.

That is the big stuff. I have to admit I structure my projects (or at least my scripts and functions) the way I do based on how I have seen others do it. There are far too many to properly credit...but I would say my biggest influence is Gaia. His scripts and functions are always well organized and easy to follow.

[sbsmac 0]

I organise my 'scripts' just like I would any other code :) ...

* Functions are the building blocks and are declared using syntax like

moveUnit={ARG0 setpos ARG1;} ;

* Related functions are grouped into libraries which live in a single file (or group of files for larger libraries).

* A common header file is used to define some basic syntactic 'sugar' (Eg, "#define ARG0 (_this select 0)"

The only real sqf specific stuff is the necessity to 'import' libraries during init.sqf. Eg...

call compile preprocessfile "unitFunctions.sqf";
//Now we can call moveUnit whenever we want to.

[igneous01 19]

@sbsmac - i more or less do the same thing. Depending on how many functions are needed in the script, they are either kept in a separate file that is the master library, or split into smaller libraries depending on complexity.

So it seems that Im not the only one who works like this (funny, considering most scripts i open up have a different format)