Lou Montana/Sandbox – User

ⓘ

Future Code Best Practices page

---

Category: Scripting Topics

Getting started

In the domain of development, any rule is a rule of thumb. If a rule states for example that it is better that a line of code doesn't go over 80 characters, it doesn't mean that any line must not go over 80 characters; sometimes, the situation needs it. If you have a good structure, do not change your code to enforce a single arbitrary rule. If you break many of them, you may have to change something; again, this is according to your judgement.

With that being said, let's go!

Prerequisites

• Interest!
• An Arma game
• An advanced text editor such as Visual Studio Code or Notepad++ (see Debugging Techniques' Code Edition chapter for useful plugins)
• Some English knowledge, helped if needed by a translator tool like Google Translate or DeepL
• Access to this wiki is a plus (the Swiss flag is, too)
• Tutorial/examples (YouTube tutorials, community tutorials, Example Code)
• Google-Fu (a.k.a search engine skills)

Best practices

Code format

• Whatever you do about your code's format, be consistent.
• Choose an indentation format and stick to it. There is not especially one indent better than another (but there sure are terrible ones), again the important point here being consistency.
  • Common indentation styles are:
    • K&R style indenting
    • Allman style indenting
  • Use empty space. Line return, spaces before and after brackets, if this improves readability, use it: space is free.
  • indent with two/four spaces or one tab. Do not mix these.
  • One-lining (putting everything in one statement) memory improvement is most of the time not worth the headache it gives when trying to read it. Don't overuse it.
• 0 = myCommand is "useful" only for editor fields that for no apparent reason refuse commands returning a value.
  You do not need it in script files.

Variable format

• Name your variables and functions properly: While SQF is (non-noticeably) impacted by variable name length, this should not take precedence on the fact that code must be readable by a human being.
  • Your variable names must have a meaning: variables like _u instead of _uniform should not exist. _i is an accepted iteration variable name (e.g in for loops).
  • It is recommended to use camel-case your variables; camel-casing (namingLikeThis) your variables and functions make the code naturally more readable, especially for long names.
• Prefix your public variables and setVariable with your tag in order to avoid any conflict about other mods, scripts or mission variables.
• Make your variables private thanks to the private or params keyword in order to avoid accidental upper-scope overwriting of variables of the same name.
• Defined constants must be UPPERCASE_WITH_UNDERSCORES (e.g #define SOME_CONST).

Code structuration

• DRY: Don't Repeat Yourself. If you write the same code block or the same logic many times, export this code as a function and use parameters with it.
  • If your code has too many levels, it is time to split and rethink it (e.g if (something) then { if (somethingElse) then { if (anotherSomething) then { /* etc */ }; }; };...)
  • Do NOT use macros as functions - these hinder readability. Use functions instead.
• Using comments in your code must not explain what the code does, but why it is done this way (if needed). Your code organisation combined to your variable names must be enough to be read by a human.

Code/Files organisation

• Use CfgFunctions to declare the functions that will be called frequently.
  • One Functions directory, with sub-directories if needed.
• Use Event Scripts as needed.
• Don't put any code in a unit's init box but eventually local commands for this specific unit - all unit's init boxes are run client-side on client connection.

Examples

Bad Example	Good Example
Good Practice Examples
_unit = player;	private _unit = player;
private _uB = allUnits select { side _x == blufor };	private _bluforUnits = allUnits select { side _x == blufor };
finalAssault = true; publicVariable "finalAssault";	PREFIX_finalAssault = true; publicVariable "PREFIX_finalAssault";
player setVariable ["MoneyInPocket", true];	player setVariable ["PREFIX_MoneyInPocket", true];
Format Examples
if (alive player && damage player >= 0.9) then { hint "very damaged"; }; if (alive player && damage player >= 0.5 && damage player < 0.9) then { hint "quite damaged"; }; if (alive player && damage player > 0 && damage player < 0.5) then { hint "slightly damaged"; }; if (alive player && damage player == 0) then { hint "pristine state"; }; if (not alive player) then { hint "dead"; };	if (not alive player) exitWith { hint "dead"; }; private _playerDamage = damage player; switch (true) do { case (_playerDamage >= 0.9): { hint "very damaged"; }; case (_playerDamage >= 0.5): { hint "quite damaged"; }; case (_playerDamage > 0)  : { hint "slightly damaged"; }; default { hint "pristine"; }; };

Final words

• Learn from others' scripts but don't steal code and pretend it's yours — be a decent human being. Stealing code and its consequences:
  • It soils your reputation and devaluates your actions once it is found out — and it always get found out. DMCA's are filled on Steam every day.
  • It makes people in the community get less helpful and more reluctant in giving advices. It can also prevent them to release an interesting feature!
• Don't try to obfuscate your code: it is considered rude, especially since you learnt from others.
  • Obfuscated code only makes it harder to get, but does not make it protected.
  • Obfuscated code is also slower on compilation (and, depending on the quality of code and obfuscation, on execution too).
• Have fun!