mirrors
/
Nuklear
mirror of https://github.com/Immediate-Mode-UI/Nuklear
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add reviewers guide to readme (#72) 

Add reviewers guide to Readme.md
This commit is contained in:
Jimmi Holst Christensen 2020-03-08 20:19:30 +01:00 committed by GitHub
parent 82d85e94e1
commit 177f391347
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 35 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
Readme.md
View File

@ -167,3 +167,38 @@ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-----------------------------------------------------------------------------
```
## Reviewers guide
When reviewing pull request there are common things a reviewer should keep
in mind.
Reviewing changes to `src/*` and `nuklear.h`:
* Ensure C89 compatibility.
* The code should work for several backends to an acceptable degree.
* Recommend simple optimizations.
* Pass small structs by value instead of by pointer.
* Use local buffers over heap allocation when possible.
* Check that the coding style is consistent with code around it.
* Variable/function name casing.
* Indentation.
* Curly bracket (`{}`) placement.
* Ensure that the contributer have bumped the appropriate version in
[package.json](https://github.com/Immediate-Mode-UI/Nuklear/blob/master/package.json)
and added their changes to the
[CHANGELOG](https://github.com/Immediate-Mode-UI/Nuklear/blob/master/src/CHANGELOG).
* Have at least one other person review the changes before merging.
Reviewing changes to `demo/*`, `example/*` and other files in the repo:
* Focus on getting working code merged.
* We want to make it easy for people to get started with Nuklear, and any
`demo` and `example` improvements helps in this regard.
* Use of newer C features, or even other languages is not discouraged.
* If another language is used, ensure that the build process is easy to figure out.
* Messy or less efficient code can be merged so long as these outliers are pointed out
and easy to find.
* Version shouldn't be bumped for these changes.
* Changes that improves code to be more inline with `nuklear.h` are ofc always welcome.