Skip to content
Browse files

Updated the contribution guidelines (#180)

* Added more details about Hazel coding conventions to contribution guidelines
* Added bullet about using closing keywords in PRs
* Added descriptive commit messages hint
* Check if code actualy compiles and runs
  • Loading branch information
Puddlestomper authored and LovelySanta committed Dec 18, 2019
1 parent ed86c74 commit 7e9792175c646380e535ace711731743b91b3381
Showing with 22 additions and 2 deletions.
  1. +22 −2 .github/
@@ -42,19 +42,37 @@ You've created a new fix or feature for Hazel. Awesome!

4. Give us a moment. Hazel is maintained by only a few people, all of whom are doing this on their limited free time, so it may take us a bit to review your request. Bug fixes should be merged in directly, while features usually require Cherno's approval with or without it mentioned in one (or more) videos.

If you're not sure what any of that means, check out Thinkful's [GitHub Pull Request Tutorial]( for a complete walkthrough of the process.
If you're not sure what any of that means, check out Thinkful's [GitHub Pull Request Tutorial][thinkful-pr-tutorial] for a complete walkthrough of the process.

### Writing a Good Pull Request

- Stay focused on a single fix or feature. If you submit multiple changes in a single request, we may like some but spot issues with others. When that happens, we have to reject the whole thing. If you submit each change in its own request it is easier for us to review and approve.

- Limit your changes to only what is required to implement the fix or feature. In particular, avoid style or formatting tools that may modify the formatting of other areas of the code.

- Use descriptive commit titles/messages. "Implemented \<feature\>" or "Fixed \<problem\> is better than "Updated \<file\>".

- Make sure the code you submit compiles and runs without issues. When we set up unit tests and continuous integration we also expect that the pull request should pass all tests.

- Use [closing keywords][github-help-closing-keywords] in the appropriate section of our Pull Request template where applicable.

- Follow our coding conventions, which we've intentionally kept quite minimal.

### Coding Conventions

- For variables we use readable camel case: `doSomethingCool`. If they are class members use the 'm_' prefix: `m_DoSomethingCool`. When they are static use the 's_' prefix: `s_DoSomethingCool`.
- Naming convention:
- For functions we use pascal case: **`FunctionName`**.
- For (scoped) variables and function parameters we use camel case: **`variableName`** and **`parameterName`**.

- For class names we use pascal case: **`ClassName`**.

- For class variables we use the Hungarian notation:
- Class member variables get the 'm_' prefix: **`m_ClassMemberVariableName`**.
- Class static variables get the 's_' prefix: **`s_ClassStaticVariableName`**.

- For macros we use snake case: **`MACRO_NAME`**.
- If it is specifically related to Hazel, we add the 'HZ_' prefix: **`HZ_MACRO_NAME`**.
- If there is a macro for the application and for the engine, we add an additional 'CORE_' prefix to the engine macro: **`HZ_CORE_MACRO_NAME`**.

- Use tabs for indentation, not spaces.

@@ -66,3 +84,5 @@ If you're not sure what any of that means, check out Thinkful's [GitHub Pull Req

0 comments on commit 7e97921

Please sign in to comment.
You can’t perform that action at this time.