|
| 1 | +# Getting started |
| 2 | + |
| 3 | +To start off you can check out existing Pull Requests and Issues to get a gasp of what problems we’re currently solving and what features you can implement. |
| 4 | + |
| 5 | +## Issues |
| 6 | + |
| 7 | +Our issues are mostly used for bugs, however we welcome refactoring and conceptual issues. |
| 8 | + |
| 9 | +Any other conversation would belong and would be moved into “Discussions”. |
| 10 | + |
| 11 | +## Discussions |
| 12 | + |
| 13 | +We use discussions for ideas, polls, announcements and help questions. |
| 14 | + |
| 15 | +Don’t hesitate to ask, we always would try to help. |
| 16 | + |
| 17 | +## Pull Requests |
| 18 | + |
| 19 | +If you want to help us by improving existing or adding new features, you create what’s called a Pull Request (aka PR). It allows us to review your code, suggest changes and merge it. |
| 20 | + |
| 21 | +Here are some tips on how to make a good first PR: |
| 22 | + |
| 23 | +- When creating a PR, please consider a distinctive name and description for it, so the maintainers can understand what your PR changes / adds / removes. |
| 24 | +- It’s always a good idea to link documentation when implementing a new feature / endpoint |
| 25 | +- If you’re resolving an issue, don’t forget to [link it](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) in the description. |
| 26 | +- Enable the checkbox to allow maintainers to edit your PR and make commits in the PR branch when necessary. |
| 27 | +- We may ask for changes, usually through suggestions or pull request comments. You can apply suggestions right in the UI. Any other change needs to be done manually. |
| 28 | +- Don’t forget to mark PR comments resolved when you’re done applying the changes. |
| 29 | +- Be patient and don’t close and reopen your PR when no one responds, sometimes it might be held for a while. There might be a lot of reasons: release preparation, the feature is not significant, maintainers are busy, etc. |
| 30 | + |
| 31 | + |
| 32 | +When your changes are still incomplete (i.e. in Work In Progress state), you can still create a PR, but consider making it a draft. |
| 33 | +To make a draft PR, you can change the type of PR by clicking to a triangle next to the “Create Pull Request” button. |
| 34 | + |
| 35 | +Once you’re done, you can mark it as “Ready for review”, and we’ll get right on it. |
| 36 | + |
| 37 | + |
| 38 | +# Code style |
| 39 | + |
| 40 | +To standardize and make things less messy we have a certain code style, that is persistent throughout the codebase. |
| 41 | + |
| 42 | +## Naming |
| 43 | + |
| 44 | +### REST methods |
| 45 | + |
| 46 | +When naming a REST method, while it might seem counterintuitive, we specify the entity before the action verb (for GET endpoints we don’t specify one however). Here’s an example: |
| 47 | + |
| 48 | +> Endpoint name: Get Channel Message |
| 49 | +> |
| 50 | +> Method name: `ChannelMessage` |
| 51 | +
|
| 52 | +> Endpoint name: Edit Channel Message |
| 53 | +> |
| 54 | +> Method name: `ChannelMessageEdit` |
| 55 | +
|
| 56 | +### Parameter structures |
| 57 | + |
| 58 | +When making a complex REST endpoint, sometimes you might need to implement a `Param` structure. This structure contains parameters for certain endpoint/set of endpoints. |
| 59 | + |
| 60 | +- If an endpoint/set of endpoints have mostly same parameters, it’s a good idea to use a single `Param` structure for them. Here’s an example: |
| 61 | + |
| 62 | + > Endpoint: `GuildMemberEdit` |
| 63 | + > |
| 64 | + > `Param` structure: `GuildMemberParams` |
| 65 | +- If an endpoint/set of endpoints have differentiating parameters, `Param` structure can be named after the endpoint’s verb. Here’s an example: |
| 66 | + |
| 67 | + > Endpoint: `ChannelMessageSendComplex` |
| 68 | + > |
| 69 | + > `Param` structure: `MessageSend` |
| 70 | + |
| 71 | + > Endpoint: `ChannelMessageEditComplex` |
| 72 | + > |
| 73 | + > `Param` structure: `MessageEdit` |
| 74 | +
|
| 75 | +### Events |
| 76 | + |
| 77 | +When naming an event, we follow gateway’s internal naming (which often matches with the official event name in the docs). Here’s an example: |
| 78 | + |
| 79 | +> Event name: Interaction Create (`INTERACTION_CREATE`) |
| 80 | +> |
| 81 | +> Structure name: `InteractionCreate` |
| 82 | +
|
| 83 | +## Returns |
| 84 | + |
| 85 | +In our REST functions we usually favor named returns instead of regular anonymous returns. This helps readability. |
| 86 | + |
| 87 | +Additionally we try to avoid naked return statements for functions with a long body. Since it’s easier to loose track of the return result. |
0 commit comments