Use common sense
These are conventions which we try to follow when writing code for ScummVM. Sticking to a common set of formatting / indention rules makes it easier to read through our source base (which now exceed half a million lines of code by far, making this quite important). If you want to submit patches, please try to adhere to these rules.
We don't always follow these rules slavishly, in certain cases it is OK (and in fact might be favorable) to stray from them. Applying common sense, as usual, is a good idea.
In the following examples tabs are replaced by spaces for visual consistency with the Code Formatting Conventions. But in actual code, use tabs for indentations (our tabs are assumed to be 4 spaces wide).
Hugging braces
Braces in your code should look like the following example:
for (int i = 0; i < t; i++) {
[...]
}
if (j < k) {
[...]
} else {
[...]
}
class Dummy() {
[...]
};
Did you see the {}'s on that?
Tab indents, with tabstop at four spaces
Says it all, really.
Whitespaces
Conventional operators surrounded by a space character
a = (b + c) * d;
C++ reserved words separated from opening parentheses by a white space
while (true) {
Commas followed by a white space
someFunction(a, b, c); int d, e;
Semicolons followed by a space character, if there is more on line
for (int a = 0; b++; c < d) doSomething(e); doSomething(f); // This is probably bad style anyway
When declaring class inheritance and in a ? construct, colons should be surrounded by white space
class BusWheel : public RubberInflatable {
(isNight) ? colorMeDark() : colorMeBright();
Indentation level is not increased after namespace clause
namespace Scumm {
byte Actor::kInvalidBox = 0;
void Actor::initActorClass(ScummEngine *scumm) {
_vm = scumm;
}
} // End of namespace Scumm
Array delete operator has no whitespace before []
delete[] foo;
Template definitions
No whitespace between template keyword and <
template<typename foo>
void myFunc(foo arg) {
// ...
}
Operator overloading
Operator keyword is NOT separated from the name, except for type conversion operators where it is required.
struct Foo {
void operator()() {
// ...
}
operator bool() {
return true;
}
};
Pointers and casts
No whitespace after a cast; and in a pointer, we write a whitespace before the start but not after it.
const char *ptr = (const char *)foobar;
Switch / Case constructs
switch (cmd) {
case kSaveCmd:
save();
break;
case kLoadCmd:
case kPlayCmd:
close();
break;
default:
Dialog::handleCommand(sender, cmd, data);
}
Naming
Constants
Basically, you have two choices (this has historical reasons, and we probably should try to unify this one day):
- Camel case with prefix 'k':
kSomeKludgyConstantName
- All upper case, with words separated by underscores (no leading/trailing underscores):
SOME_KLUDGY_CONSTANT_NAME
(As a side remark, we recommend avoiding #define for creating constants, because these can lead to weird and difficult to track down conflicts. Instead use enums or the const keyword.)
Classes
Camel case starting with upper case.
class MeClass() {
Class member variables
Prefixed with '_' and in camel case (Yo! no underscore separators), starting with lowercase.
char *_someVariableName;
Class methods
Camel case, starting with lowercase.
void thisIsMyFancyMethod();
Global variables
In general you should avoid global variables, but if it can't be avoided, use 'g_' as prefix, camel case, and start with lowercase
int g_someGlobaleVariable;
Special comments
Special Keywords
The following goes slightly beyond code formatting: We use certain keywords (together with an explanatory text) to mark certain sections of our code. In particular:
- FIXME marks code that contains hacks or bad temporary workarounds, things that really should be revised at a later point.
- TODO marks incomplete code, or things that could be done better but are left for the future.
- WORKAROUND marks code that works around bugs in the original game, like script bugs. Sometimes these bugs worked in the original due to bugs in the original engine, sometimes the bug was visible in the original, too. It's important that you explain here what exactly you work around, and if applicable, refer to relevant tracker items!
Doxygen documentation comments
ScummVM uses the Doxygen software to generate HTML documentation for the codebase (available here).
Doxygen supports documentation blocks. These are specially-formatted comments that doxygen prints out in the generated documentation. They are similar in purpose to Java's JavaDoc or Python's docstrings.
There are many ways to mark such comments, but developers are encouraged to use the JavaDoc style:
/**
* Move ("warp") the mouse cursor to the specified position in virtual
* screen coordinates.
* @param x the new x position of the mouse
* @param y the new y position of the mouse
*/
virtual void warpMouse(int x, int y) = 0;
(See here for the docs generated from this.)
As shown in the example, documentation blocks also support several special commands such as param. Those are prefixed with either @ or \, but developers should always use @.
If you want to add a brief explanation of a variable or function after its declaration, this is the correct syntax:
int16 x; //!< The horizontal part of the point int16 y; //!< The vertical part of the point
(See here for the docs generated from this.)
For more information, visit the official documentation:
Automatically converting code to our conventions
The following settings for Artistic Style (als known as astyle) approximate our code formatting convetions and can be used to quickly convert a big bunch of source files to our conventions. Note that you still may have to manually clean up some stuff afterwards.
indent=tab=4 brackets=attach indent-classes pad=oper unpad=paren