-
Notifications
You must be signed in to change notification settings - Fork 11
SQF standard recommendation
This section of the standard comprises what should be considered the standard coding elements that are required to ensure a high level of technical interoperability between shared SQF code.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
- Files MUST use only UTF-8 without BOM.
- Variable names MUST be declared in
camelCase
. - Method names MUST be declared in
camelCase
. - Code MUST use 4 spaces for indenting, not tabs.
- There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
- Constants MUST be declared in all upper case with underscore separators.
- Control structure keywords MUST have one space after them; method and function calls MUST NOT.
- Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
- Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.
All folders SHOULD be named in StudlyCaps
.
All files SHOULD be named in camelCase
.
All files MUST use the Unix LF (linefeed) line ending.
All files MUST end with a single line, containing only a single newline (LF) character.
SQF code MUST use only UTF-8 without BOM.
All SQF files MUST have the .sqf
extension.
All Header files MUST have the .hpp
extension. The only exception is the config.cpp
file.
There MUST NOT be a hard limit on line length.
The soft limit on line length MUST be 120 characters; automated style checkers MUST warn but MUST NOT error at the soft limit.
Lines SHOULD NOT be longer than 80 characters; lines longer than that SHOULD be split into multiple subsequent lines of no more than 80 characters each.
There MUST NOT be trailing whitespace at the end of lines.
Blank lines MAY be added to improve readability and to indicate related blocks of code except where explicitly forbidden.
There MUST NOT be more than one statement per line.
Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
N.b.: Using only spaces, and not mixing spaces with tabs, helps to avoid problems with diffs, patches, history, and annotations. The use of spaces also makes it easy to insert fine-grained sub-indentation for inter-line alignment.
All comments SHOULD be well-written, clear and meaningful. All comments MUST be up-to-date.
Line comments MUST use //
characters followed by a single space.
Use block comments for formal documentations such as file headers.
Block comments MUST start in a new line with /*
followed by a single newline (LF) character.
Block comments MUST end in a new line with */
followed by a single newline (LF) character.
Each line inside a block comment MUST start with *
.
All variable names MUST be declared in camelCase
.
All global variables MUST start with a prefix followed by the module name, separated by underscores.
Global variables MUST NOT contain the fnc
prefix if the value is not callable code.
Example: PREFIX_Module_variableName
For AAW this is done automatically with the GVAR macro.
Global variables SHOULD NOT be used to pass along information from one function to another. Use arguments instead.
All private variables MUST start with a single underscore.
The first occurrence in a file SHOULD be preceded by the private
command. Exceptions are recursive functions.
All private variables SHOULD use self-explanatory names and SHOULD NOT use single character names
Example: _velocity
instead of _v
Every operator MUST be encapsulated in spaces.
There MUST be one space after the control structure keyword. There MUST NOT be a space after the opening parenthesis/braces. There MUST NOT be a space before the closing parenthesis/braces. The structure body MUST be indented once. The closing brace MUST be on the next line after the body.
An if
structure looks like the following. Note the placement of parentheses, spaces and brace; and that else
is on the same line as the closing brace from the earlier body.
if (expression) then {
// if body
} else {
// else body
};
A switch
structure looks like the following.
The case
statement MUST be indented once from switch
.
switch (variable) do {
case 0: {
hint "First case";
};
case 1;
case 2: {
hint "Case for 1 and 2";
};
default {
hint "Default case";
};
};
while {} do {
};