Skip to content
commy2 edited this page Dec 17, 2014 · 9 revisions

To make AGM's code nice and uniform, here are some standards that shall be used whenever contributing code to AGM.

Indentation

2 spaces for indentation.

class Something: Or {
..class Other {
....foo = "bar";
..};
};

Reasoning

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.

Braces

  • 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;};

Reasoning

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.

Variables

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.

Functions

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.

Remote/Global code execution

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.

Animations

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.

player / isPlayer

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.


Disclaimer

Some of AGM's code currently violates some of these rules. That will be fixed eventually. :>