mirror of
https://github.com/Palakis/obs-websocket.git
synced 2024-08-30 18:12:16 +00:00
88 lines
3.4 KiB
Markdown
88 lines
3.4 KiB
Markdown
# Contributing to obs-websocket
|
|
|
|
## Translating obs-websocket to your language
|
|
|
|
Localization happens on [Crowdin](https://crowdin.com/project/obs-websocket)
|
|
|
|
## Branches
|
|
|
|
**Development happens on `master`**
|
|
|
|
## Writing code for obs-websocket
|
|
|
|
### Code Formatting Guidelines
|
|
|
|
* Function and variable names: camelCase for variables, MixedCaps for method names
|
|
|
|
* Request and Event names should use MixedCaps names. Keep naming conformity of request naming using similar terms like `Get`, `Set`, `Get[x]List`, `Start[x]`, `Toggle[x]`.
|
|
|
|
* Request and Event json properties/fields should use camelCase. Try to use existing property names.
|
|
|
|
* Code is indented with Tabs. Assume they are 4 columns wide
|
|
|
|
* 80 columns max code width. (Comments/docs can be larger)
|
|
|
|
* New and updated requests/events must always come with accompanying documentation comments (see existing protocol elements for examples).
|
|
These are required to automatically generate the [protocol specification document](docs/generated/protocol.md).
|
|
|
|
### Code Best-Practices
|
|
|
|
* Favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this:
|
|
```cpp
|
|
if (success) {
|
|
return RequestResult::Success();
|
|
} else {
|
|
return RequestResult::Error(RequestStatus::GenericError);
|
|
}
|
|
```
|
|
is better like this:
|
|
```cpp
|
|
if (!success) {
|
|
return RequestResult::Error(RequestStatus::GenericError);
|
|
}
|
|
return RequestResult::Success();
|
|
```
|
|
|
|
* Try to use the [built-in](https://github.com/Palakis/obs-websocket/blob/master/src/requesthandler/rpc/Request.h) request checks when possible.
|
|
* Refer to existing requests for usage examples.
|
|
|
|
* Some example common response/request property names are:
|
|
* `sceneName` - The name of a scene
|
|
* `inputName` - The name of an input
|
|
* `sourceName` - The name of a source (only for when multiple source types apply)
|
|
* `sceneItemEnabled` - Whether a scene item is enabled
|
|
|
|
* Response parameters which have no attributed data due to an invalid state should be set to `null` (versus being left out)
|
|
* For example, when `GetSceneList` is called and OBS is not in studio mode, `currentPreviewSceneName` will be `null`
|
|
* If a request's core response data depends on a state, an error should be thrown unless `ignoreNonFatalRequestChecks` is set. See `GetCurrentPreviewScene` as an example.
|
|
|
|
### Commit Guidelines
|
|
|
|
* Commits follow the 50/72 standard:
|
|
* 50 characters max for the commit title (excluding scope name)
|
|
* One empty line after the title
|
|
* Description wrapped to 72 columns max width per line.
|
|
|
|
* Commit titles:
|
|
* Use present tense
|
|
* Prefix the title with a "scope" name
|
|
* e.g: "CI: fix wrong behaviour when packaging for OS X"
|
|
* Typical scopes: CI, General, Requests, Events, Server
|
|
|
|
**Example commit:**
|
|
|
|
```
|
|
Requests: Add GetSceneList
|
|
|
|
Adds a new request called `GetSceneList` which returns the current
|
|
scene, along with an array of objects, each one with a scene name
|
|
and index.
|
|
```
|
|
|
|
### Pull Requests
|
|
|
|
* Pull Requests must never be based off your fork's main branch (in this case, `master`).
|
|
* Start your work in a newly named branch based on the upstream main one (e.g.: `feature/cool-new-feature`, `bugfix/fix-palakis-mistakes`, ...)
|
|
|
|
* If your work is not done yet, but for any reason you need to PR it (like collecting discussions, testing with CI, getting testers),
|
|
create it as a Draft Pull Request (open the little arrow menu next to the "Create pull request" button, then select "Create draft pull request"). |