Formatting

We have set up a .clang-format definition that should be used for automatically formatting the code to the project code style. The formatting is based on the WebKit-code style, with some adjustments to better fit the original code style found in the project. Note that we only follow the formatting part of the WebKit style (i.e., everything clang-format automatically cleans up).

To avoid uninitialized variables, local variable declarations should happen at the first statement. See the example below:

Good:

int f() {
	int x = 5;
	return x;
}

Bad:

int f() {
	int x;
	x = 5;
	return x;
}

Data Types

In general, you should use standard C++ types like uint8_t, uint16_t, uint32_t, etc., instead of SDL types like Uint8, Uint16, Uint32.

Some globals and parameters are using Hungarian notation specifying the type. The ones we've identified so far are the following:

uint8_t bLen;
bool isEnabled;
uint16_t wLen;
uint32_t dwLen;
size_t nLen;
static bool sgbSomeFlag;
static uint32_t sgdwSomeDword;

Booleans

true/false should be used in all cases as boolean literals.

Unsigned Integers

Use uint8_t, uint16_t, uint32_t, size_t, or uint64_t.

Signed Integers

Avoid char as it can be signed or unsigned depending on the platform; use int8_t unless it's a C-string.

Use int8_t, int16_t, int32_t, int64_t.

Rules

Pointers

Null pointers should use nullptr instead of 0 to stand out more between numeric values.

Increments and Decrements

Avoid all increments/decrements used as expressions and try to write the code to include them as statements unless it would contradict other rules.

Avoid:

foo[++count] = 0;

Prefer:

count++;
foo[count] = 0;

Avoid pre-increments/pre-decrements whenever possible. The default should be foo++/foo--.

Conditions/Checks (esp. Zero/Falsy Checks)

• Booleans: Use the expression itself: if (!condition)
• Pointers: Use explicit comparisons with nullptr: if (ptr == nullptr)
• Integers: Use explicit comparisons with 0: if (count == 0)

Reasoning: Comparing with the literals of the right type makes the intent of the check clearer in many cases.

Adding Notes for Translators

If you create a new string visible to the user, please make sure to include a note for translators if the context isn't clear. Since we are using an automated process to export the strings, please follow this style:

• Short notes can be done inline: _( /* TRANSLATORS: New UI Element showing foo bar */ "foo bar"),
• For more complex explanations please use // TRANSLATORS: as a comment before printing the message.

Example:

// TRANSLATORS: This here is the new UI function a player can toggle via the diablo.ini. %s will be the player name %i the player's level. [...]
sprintf(msg, _("%s is level %i.")

Note: Poedit will look for the Tags _, N_, and ngettext to export a string for translation. The usage of TRANSLATORS: will export the text as a note for translators. Other comments will be ignored.

Comments

Use Doxygen style for documentation of the code.