From 7a7a8b7ed123f52fb7467cba64b27be9bc4c5e28 Mon Sep 17 00:00:00 2001
From: tt2468 <tt2468@gmail.com>
Date: Thu, 14 May 2020 03:19:14 -0700
Subject: [PATCH] Docs: Even more changes
---
CONTRIBUTING.md | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index a319e63d..2b2fff1d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -12,22 +12,22 @@ Localization happens on [Crowdin](https://crowdin.com/project/obs-websocket)
### Code Formatting Guidelines
- - Function and variable names: snake_case for C names, MixedCaps for C++ names
+- Function and variable names: snake_case for C names, MixedCaps for C++ names
- - Request and Event names should use MixedCaps names
+- Request and Event names should use MixedCaps names
- - Request and Event json properties should use camelCase. For more detailed info on property naming, see [Google's JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml)
+- Request and Event json properties should use camelCase. For more detailed info on property naming, see [Google's JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml)
- - Tabs are 8 columns wide
+- Tabs are 8 columns wide
- - 80 columns max code width. (Docs can be larger)
+- 80 columns max code width. (Docs can be larger)
- - New and updated requests/events must always come with accompanying documentation comments (see existing protocol elements for examples).
+- 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:
+- Favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this:
```cpp
if (success) {
return req->SendOKResponse();
@@ -45,16 +45,16 @@ return req->SendOKResponse();
### 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.
+- 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
+- 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:**
@@ -68,10 +68,10 @@ transitions.
### Pull Requests
- - Pull Requests must never be based off your fork's main branch (in this case, `4.x-current`).
- - Start your work in a newly named branch based on the upstream main one (e.g.: `feature/cool-new-feature`, `bugfix/fix-palakis-mistakes`, ...)
+- Pull Requests must never be based off your fork's main branch (in this case, `4.x-current`).
+ - Start your work in a newly named branch based on the upstream main one (e.g.: `feature/cool-new-feature`, `bugfix/fix-palakis-mistakes`, ...)
- - Only open a pull request if you are ready to show off your work.
+- Only open a pull request if you are ready to show off your work.
- - If your work is not done yet, but for any reason you need to PR it (like collecting discussions, testing with CI, getting testers),
+- 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").