-
Notifications
You must be signed in to change notification settings - Fork 84
Coding Guidelines
To make AGM's code nice and uniform, here are some standards that shall be used whenever contributing code to AGM.
2 spaces for indentation.
class Something: Or {
..class Other {
....foo = "bar";
..};
};
Tabs can be tricky sometimes, especially when it comes to sharing code with others. Additionally, a lot of people tend to forget they're using tabs when they're aligning things after the first character, which causes things to fall apart when viewing the code at different tab lengths. Only 2 spaces because class structures can get quite deep, and 4 spaces would cause the code to take the entirety of your monitor.
- opening bracket on the same line as keyword
- closing bracket in own line, same level of indentation as keyword
Yes:
class Something: Or {
class Other {
foo = "bar";
};
};
No:
class Something : Or
{
class Other
{
foo = "bar";
};
};
Also no:
class Something : Or {
class Other {
foo = "bar";
};
};
When using if
/else
, it is encouraged to put else
on the same line as the closing bracket to save space:
if (alive player) then {
player setDamage 1;
} else {
hint ":(";
};
In cases where you , e.g, have a lot of one-liner classes, it is allowed to use something like this to save space:
class One {foo = 1;};
class Two {foo = 2;};
class Three {foo = 3;};
Putting the opening bracket in it's own line wastes a lot of space, and keeping the closing bracket on the same level as the keyword makes it easier to recognize what exactly the bracket closes.
Everything that might occur in a global context should be prefixed with AGM_ and, if necessary, the containing PBO (AGM_Medical_xxx etc.). This includes stringtable entries!
Local variables should be "privatized" in most cases, to avoid unwanted namespace issues.
Whenever possible, use BIS' function system instead of manually compiling script files. This makes it easier to debug things in game and gives third-party developers an easier time using AGM functions.
All functions should include a comment at the top stating:
- Author
- Description
- Arguments with description and type
- Return Value
If you have a very specific function you need for something like recursion, it is fine to use a local function.
Whenever you need to execute a command globally or on a machine where a specific vehicle/unit is local, please use AGM_Core_fnc_execRemoteFnc
. This makes especially the second case a lot easier and reduces overhead. For documentation please consult the function header.
Use AGM_Core_fnc_doAnimation
. This handles edge cases like prevent your animation from breaking unconsciousness for you and also handles locality for switchMove
. For documentation please consult the function header.
To make sure that your code works with Zeus remote control, please use the global variable AGM_player
instead of player
and use [_myunit] call AGM_Core_fnc_isPlayer
instead of isPlayer _myunit
.
On some initilization eventhandlers like Init and Respawn you might want to use call AGM_Core_fnc_player
in case AGM_player
isn't reset yet.
Some of AGM's code currently violates some of these rules. That will be fixed eventually. :>