Skip to content
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
wants to merge 2 commits into from
Closed

Add a style guide so future users know how to format their code for contribution #1706

wants to merge 2 commits into from

Conversation

rawr51919
Copy link
Contributor

@rawr51919 rawr51919 commented Jul 11, 2022

Description

Adds a style guide so it's easy to show what is expected from future contributors and their work.
Port from pret/pokefirered#63
Fixes #598

Discord contact info

chloerawr(female symbol)#5011

This function was the same in both pokeruby and pokeemerald so it's safe to port this contributing.md from pokeruby to pokeemerald
@rawr51919 rawr51919 changed the title Port CONTRIBUTING.md from pokeruby Add a style guide so future users know how to format their code for contribution Jul 11, 2022
Copy link
Collaborator

@mrgriffin mrgriffin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this style guide should mention other conventions such as:

CB1_/CB2_ as a prefix for things intended for use as a MainCallback (depending on whether they're callback1 or callback2).
VBlank_ as a prefix for things intended for use as a VBlank interrupt handler.
Task_ as a prefix for tasks, u8 taskId as its argument, s16 *data = &gTasks[taskId].data; as a local alias for data. The use of #define tName data[X] to label task data.
FieldCB_ as a prefix for functions assigned to gFieldCallback.

I'm sure there must be others that I've forgotten.

EDIT:
The use of src/data/*.h as the name of files we include in a single src/*.c file so that code isn't intermingled with gigantic arrays.
Window Templates are mostly sFooWindowTemplates, with a few sWindowTemplates_Foo.
Background Templates are mostly sFooBgTemplates (but there's a few counterexamples, e.g. sBackgroundTemplates in src/pokeblock_feed.c).

EDIT 2:
I think there's a naming scheme for tilemaps/tiles/palettes in the graphics/ folder.

EDIT 3:
ScrCmd_Foo and struct ScriptContext *ctx for things in src/scrcmd.c, and Cmd_Foo in src/battle_script_commands.c. I haven't checked, but I suspect the other bytecode interpreters also have prefixes.

Comment on lines +193 to +194
When comparing whether or not a value equals `0`, don't be explicit unless the
situation calls for it.
Copy link
Collaborator

@mrgriffin mrgriffin Jul 12, 2022

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 between 0 and FALSE 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 a boolean type would not require it, and omit == where Java would require it.

$ git grep '== \(TRUE\|FALSE\)' pret/master | wc -l
1038

@rawr51919 rawr51919 closed this by deleting the head repository Aug 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Contributing.md
2 participants