Coding Guidelines - Theseus-Aegis/TheseusServices GitHub Wiki

1. Files & Config

1.1. Header Files

All header files will always have the file name extension of .hpp.

1.2. Config Elements

Config files will be split up into different header files, each with the name of the config and be included in the config.cpp of the component.

Example:

// config.cpp
#include "CfgVehicles.hpp"

// CfgVehicles.hpp
class CfgVehicles {
    // Content
};

1.3. Stringtables

All text that will be displayed to a user shall be defined in a stingtable.xml file for multi-language support.

• There will not be any empty stringtable language values.
• All stringtables will follow the format as specified by Tabler (reference Translation Guide).

1.4. Textures & UI Pictures

All texture files should be placed in the data folder inside the component folder, have the same or at least similar name to the class name and be in .paa format.

All UI picture files should be placed in the UI folder inside the component folder, have the same or at least similar name to the class name and be in .paa format.

• Files without alpha channel shall be suffixed with _co.
• Files with alpha channel shall be suffixed with _ca.

2. Macros

2.1. Project Naming

Macro	Expanded
MAINPREFIX	x
PREFIX	tacs
SUBPREFIX	addons
COMPONENT	Specific to each module
ADDON	PREFIX_COMPONENT

2.1. Main

Macro	Expanded
QUOTE(foo)	"foo"
CLASS(foo)	PREFIX_foo
QCLASS(foo)	"PREFIX_foo"

2.2. File Paths

Macro	Expanded
PATHTOF(foo)	\MAINPREFIX\PREFIX\SUBPREFIX\COMPONENT\foo
PATHTOEF(bar,foo)	\MAINPREFIX\PREFIX\SUBPREFIX\bar\foo
QPATHTOF(foo)	"\MAINPREFIX\PREFIX\SUBPREFIX\COMPONENT\foo"
QPATHTOEF(bar,foo)	"\MAINPREFIX\PREFIX\SUBPREFIX\bar\foo"

2.3. Stringtables

Macro	Expanded
CSTRING(foo)	"$STR_ADDON_foo"
ECSTRING(bar,foo)	"$STR_PREFIX_bar_foo"

2.4. Multiple Strings

Macro	Expanded
ITEMS_n(foo)	n times repeated foo in format foo, foo, foo ...

2.5. Container

Macro	Expanded
MACRO_ADDWEAPON(bar,foo)	class _xx_bar { weapon = "bar"; count = foo; };
MACRO_ADDITEM(bar,foo)	class _xx_bar { name = "bar"; count = foo; };
MACRO_ADDMAGAZINE(bar,foo)	class _xx_bar { magazine = "bar"; count = foo; };
MACRO_ADDBACKPACK(bar,foo)	class _xx_bar { backpack = "bar"; count = foo; };

3. Code Style

3.1. Braces Placement

• Opening brace on the same line as keyword
• Closing brace 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";
    };
};

No:

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

In cases where you 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;};

3.1.1. Reasoning

Putting the opening brace in it’s own line wastes a lot of space, and keeping the closing brace on the same level as the keyword makes it easier to recognize what exactly the brace closes.

3.2. Indentation

Ever new scope should be on a new indent. This will make the code easier to understand and read. Indentations consist of 4 spaces. Tabs are not allowed.

Yes:

class Something {
    class Other {
        // Content
    };
};

No:

class Something {
        class Other {
        // Content
        };
};

3.3. Inline Comments

Inline comments should use //. Usage of /* */ is allowed for larger comment blocks.

Yes:

// Comment

Yes:

/* Loooo
ooooooong
commeeeeeent */

No:

//// Comment

Adapted from the ACE3 documentation.