In order to contribute to mGBA, there are a few things to be mindful of so as to ease the process.
New issues should be filed on the mGBA GitHub Issues tracker. When filing issues, please include the following information:
0.3-2134-4ec19aa
. On older builds, such as 0.2.1, this is not present, so please specify the version you downloaded or built. If present, this contains the version, branch name (if not master
), a revision number and a truncated revision hash. For this example, it means that it's version 0.3, on master
, commit number 2134 and revision hash 4ec19aa
. Additionally, -dirty
will be appended if there are local changes that haven't been commited.Please also describe the issue in as much detail as possible, including the name of the games you have reproduced the issue on, and how you managed to enter the buggy state. If applicable, savestates can be renamed to be .png files and attached to the issue directly.
When filing a pull request, please make sure you adhere to the coding style as outlined below, and are aware of the requirements for licensing. Furthermore, please make sure all commits in the pull request have coherent commit messages as well as the name of the component being modified in the commit message.
Some components are as follows:
mGBA aims to have a consistent, clean codebase, so when contributing code to mGBA, please adhere to the following rules. If a pull request has style errors, you will be asked to fix them before the PR will be accepted.
Variable names, including parameters, should all be in camelCase. File-scoped static variables must start with an underscore.
C struct names should start with a capital letter, and functions relating to these structs should start with the name of the class (including the capital letter) and be in camelCase after. C struct should not be typedef
ed.
Functions not associated with structs should be in camelCase throughout. Static functions not associated with structs must start with an underscore.
Enum values and #define
s should be all caps with underscores.
Good:
static int _localVariable;
struct LocalStruct {
void (*methodName)(struct LocalStruct struct, param);
int memberName;
};
enum {
ENUM_ITEM_1,
ENUM_ITEM_2
};
void LocalStructCreate(struct LocalStruct* struct);
void functionName(int argument);
static void _LocalStructUse(struct LocalStruct* struct);
static void _function2(int argument2);
C++ classes should be confined to namespaces. For the Qt port, this namespace is called QGBA
.
Class names should be handled similarly to C structs. Fields should be prefixed according to their scoping:
m_
for non-static member.s_
for static member.Braces do not go on their own lines, apart from the terminating brace. There should be a single space between the condition clause and the brace. Furthermore, braces must be used even for single-line blocks.
Good:
if (condition) {
block;
} else if (condition2) {
block2;
} else {
block3;
}
Bad (separate line):
if (condition)
{
block;
}
else if (condition2)
{
block2;
}
else
{
block3;
}
Bad (missing braces):
if (condition)
statement;
else if (condition2)
statement2;
else
statement3;
Bad (missing space):
if (condition){
block;
}
Indentation should be done using tabs and should match the level of braces. Alignment within a line should be done sparingly, but only done with spaces.
For C headers guards, the define should be the filename (including H), all-caps, with underscores instead of punctuation.
Good:
#ifndef FILE_NAME_H
#define FILE_NAME_H
// Header
#endif
There should be no comment on the #endif
.
For Qt (C++ header guards), the define should start with QGBA_
and not include _H
, but is otherwise the same. This is mostly for legacy reasons., and may change in the future.
Good:
#ifndef QGBA_FILE_NAME
#define QGBA_FILE_NAME
// Header
#endif
Block statements such as if
, while
and for
should have a space between the type of block and the parenthesis.
Good:
while (condition) {
block;
}
Bad:
while(condition) {
block;
}
In C code, use 0
instead of NULL
. This is mostly for legacy reasons and may change in the future. C code should also use bool
types and values true
and false
instead of 1
and 0
where applicable. In C++ code, use nullptr
instead of NULL
or 0
.
If a statement has no body, putting braces is not required, and a semicolon can be used. This is not required, but is suggested.
Good:
while (f());
Bad:
while (f()) {}
For infinite loops that break
statements internally, while (true)
is preferred over for (;;)
.
mGBA is licensed under the Mozilla Public License version 2.0. This entails a few things when it comes to adding code to mGBA.
third-party
section if applicable.此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。