-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a style guide so future users know how to format their code for contribution #1706
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,288 @@ | ||
# Styleguide for pokeemerald | ||
|
||
## Naming Conventions | ||
|
||
Function names and struct names should be formatted in `PascalCase`. | ||
|
||
```c | ||
void ThisIsCorrect(void); | ||
|
||
struct MyStruct | ||
{ | ||
u8 firstField; | ||
u16 secondField; | ||
... | ||
}; | ||
``` | ||
|
||
Variables and struct fields should be formatted in `camelCase`. | ||
|
||
```c | ||
int thisIsCorrect = 0; | ||
``` | ||
|
||
Global variables should be prefixed with `g`, and static variables should be | ||
prefixed with `s`. | ||
|
||
```c | ||
extern int gMyGlobalVariable; | ||
|
||
static u8 sMyStaticVariable = 0; | ||
``` | ||
|
||
Macros and constants should use `CAPS_WITH_UNDERSCORES`. | ||
|
||
```c | ||
#define MAX_LEVEL 100 | ||
|
||
enum | ||
{ | ||
COLOR_RED, | ||
COLOR_BLUE, | ||
COLOR_GREEN, | ||
}; | ||
|
||
#define ADD_FIVE(x) ((x) + 5) | ||
``` | ||
|
||
## Coding Style | ||
|
||
### Comments | ||
|
||
When describing a system/component in-depth, use block comment syntax. | ||
|
||
```c | ||
/* | ||
* This is an in-depth description of the save block format. Its format is as follows: | ||
* | ||
* Sectors 0 - 13: Save Slot 1 | ||
* Sectors 14 - 27: Save Slot 2 | ||
* ... | ||
*/ | ||
``` | ||
|
||
When briefly describing a function or block of code, use a single-line comments | ||
placed on its own line. | ||
There should be a single space directly to the right of `//`. | ||
|
||
```c | ||
// This is supplemental information for the function. If there is a bunch of info, it should | ||
// carry on to the next line. | ||
void ProcessSingleTask(void) | ||
{ | ||
// Short comment describing some noteworthy aspect of the code immediately following. | ||
... | ||
// Comments should be capitalized and end in a period. | ||
} | ||
``` | ||
|
||
When tagging a data structure that corresponds to an `enum` or some noteworthy | ||
value, place the comment on the same line as the code. | ||
```c | ||
const u8 gPlantlikeMons[] = | ||
{ | ||
FALSE, // SPECIES_BULBASAUR | ||
FALSE, // SPECIES_IVYSAUR | ||
TRUE, // SPECIES_VENUSAUR | ||
FALSE, // SPECIES_CHARMANDER | ||
... | ||
}; | ||
``` | ||
|
||
### Whitespace | ||
|
||
All `.c` and `.h` files should use 4 spaces--not tabs. | ||
Assembler files (`.s)` use tabs. | ||
|
||
### Operators | ||
|
||
Assignments and comparison operators should have one space on both sides of `=`. | ||
|
||
```c | ||
int i = 0; // correct | ||
int i=0; // incorrect | ||
|
||
a > b // correct | ||
a>b // incorrect | ||
``` | ||
|
||
The incrementor and decrementor operators should NOT have a space. | ||
|
||
```c | ||
i++; // correct | ||
i ++; // incorrect | ||
``` | ||
|
||
A control statement should have a space between them and their expressions, and the opening bracket should be on the next line. | ||
|
||
```c | ||
for (...) | ||
{ | ||
// correct | ||
} | ||
|
||
for(...) { | ||
// incorrect | ||
} | ||
``` | ||
|
||
A `switch` statement's cases should left-align with the `switch`'s block. | ||
|
||
```c | ||
switch (foo) | ||
{ | ||
case 0: // correct | ||
... | ||
break; | ||
} | ||
|
||
switch (foo) | ||
{ | ||
case 0: // incorrect | ||
... | ||
break; | ||
} | ||
``` | ||
|
||
A single empty line should follow a block. | ||
|
||
```c | ||
int MyFunction(int bar) | ||
{ | ||
int foo = 0; | ||
if (bar) | ||
foo++; | ||
|
||
return foo; // incorrect | ||
} | ||
|
||
int MyFunction(int bar) | ||
{ | ||
int foo = 0; | ||
if (bar) | ||
foo++; | ||
return foo; // incorrect | ||
} | ||
``` | ||
|
||
A chain of `if-else` statements in which any block is more than one line of | ||
code should use braces. If all blocks are single-line, then no braces are necessary. | ||
|
||
```c | ||
if (foo) // correct | ||
{ | ||
return 1; | ||
} | ||
else | ||
{ | ||
MyFunction(); | ||
return 0; | ||
} | ||
|
||
if (foo) // incorrect | ||
return 1; | ||
else | ||
{ | ||
MyFunction(); | ||
return 0; | ||
} | ||
``` | ||
|
||
### Control Structures | ||
|
||
When comparing whether or not a value equals `0`, don't be explicit unless the | ||
situation calls for it. | ||
|
||
```c | ||
if (runTasks) // correct | ||
RunTasks(); | ||
|
||
if (runTasks != 0) // incorrect | ||
RunTasks(); | ||
|
||
if (!PlayerIsOutside()) // correct | ||
RemoveSunglasses(); | ||
|
||
if (PlayerIsOutside() == 0) // incorrect | ||
RemoveSunglasses(); | ||
``` | ||
End all `switch` cases with `break`, unless omitting `break` is necessary for | ||
matching the original program flow. | ||
```c | ||
void MyFunction(void) | ||
{ | ||
switch (color) | ||
{ | ||
... | ||
case RED: | ||
... | ||
break; // correct | ||
} | ||
|
||
return; | ||
} | ||
|
||
void MyFunction(void) | ||
{ | ||
switch (color) | ||
{ | ||
... | ||
case RED: | ||
... // incorrect | ||
} | ||
|
||
return; | ||
} | ||
``` | ||
|
||
When writing a `for` or `while` loop with no body, use a semicolon `;` on the | ||
same line, rather than empty braces. | ||
|
||
```c | ||
for (i = 0; gParty[i].species != SPECIES_NONE; i++); // correct | ||
|
||
for (i = 0; gParty[i].species != SPECIES_NONE; i++) // incorrect | ||
{ } | ||
``` | ||
|
||
## Use dedicated initializers where possible | ||
|
||
In C, dedicated initializers help remove ambiguity with struct and array | ||
declarations. | ||
|
||
For arrays, you can specify the index of an element in the array by typing | ||
"[*index*] = " before the element. You can also use preprocessor constants to | ||
index an array, or an ellipsis to specify a range. For example: | ||
|
||
```C | ||
#define INDEX_8 8 | ||
static const u8 sMyArray[] = | ||
{ | ||
[9] = 9, | ||
[0 ... 4] = 1, | ||
[INDEX_8] = 8, | ||
}; | ||
``` | ||
|
||
will create the 10-element array `[1, 1, 1, 1, 1, 0, 0, 0, 8, 9]`. | ||
|
||
For structs, you can initialize specific fields using ".field = " before the | ||
value. For example: | ||
|
||
```C | ||
struct MyStruct | ||
{ | ||
u8 myFirstField; | ||
u8 mySecondField; | ||
u8 myThirdField; | ||
u8 myFourthField; | ||
}; | ||
|
||
static const struct MyStruct sMyLocalStruct = | ||
{ | ||
.mySecondField = 100, | ||
.myFourthField = 200, | ||
}; | ||
``` | ||
|
||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth mentioning that we do
== TRUE
/== FALSE
all over the place. It's bizarre to draw a distinction between0
andFALSE
in this way; it's exactly backward of how you'd expect drawing a distinction to shake out, e.g. we're saying to only write==
in situations where languages like Java with aboolean
type would not require it, and omit==
where Java would require it.