RomkaZVO/xash3d-fwgs
1
0
Fork 0
mirror of https://github.com/FWGS/xash3d-fwgs.git synced 2026-08-05 03:24:56 +08:00
Code Issues Packages Projects Releases Wiki Activity

CONTRIBUTING.md: fixed horrible grammer

Browse Source 
made contributing.md actually readable
This commit is contained in:
SLB8910
2026-07-30 11:08:03 -04:00
committed by a1batross
parent ecda80fb9a
commit 04fbe1a356
1 changed files with 22 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
CONTRIBUTING.md
View File

@@ -1,53 +1,55 @@
## If you are reporting bugs ## If you are reporting bugs
1. Check you are using latest version. You can build latest Xash3D FWGS for yourself, look to README.md. 1. Check that you are using the latest version. To build the latest Xash3D FWGS, look at README.md.
2. Check open issues is your bug is already reported and closed issues if it reported and fixed. Don't send bug if it's already reported. 2. Check the open issues to make sure your bug is not already reported and closed issues if it reported and fixed. Don't send a bug if it's already been reported.
3. Re-run engine with `-dev 2 -log` arguments, reproduce bug and post engine.log which can be found in your working directory. 3. Re-run engine with `-dev 2 -log` arguments, then reproduce the bug and post `engine.log` which can be found in your working directory.
3. Describe steps to reproduce bug. 3. Describe the steps to reproduce the bug.
4. Describe which OS and architecture you are using. 4. Describe which OS and architecture you are using.
6. Attach screenshot if it will help clarify the situation. 6. Attach a screenshot if it will help clarify the situation.
## If you are contributing code ## If you are contributing code
### Which branch? ### Which branch?
* We recommend using `master` branch. * We recommend using the `master` branch.
### Third-party libraries ### Third-party libraries
* Philosophy of any Xash Project by Uncle Mike: don't be bloated. We follow it too. * The philosophy of any Xash Project by Uncle Mike: don't be bloated. We follow it too.
* Adding new library is allowed only if there is a REAL reason to use it. It's will be nice, if you will leave a possibility to remove new dependency at build-time. * Adding new libraries are allowed only if there is a REAL reason to use it. It will be nice, if you leave a possibility to remove the new dependency at build-time.
* Adding new dependencies for Waf Build System is not welcomed. * Adding new dependencies for the Waf Build System is not welcomed.
### Portability level ### Portability level
* Xash3D have it's own crt library. It's recommended to use it. It most cases it's just a wrappers around standart C library. * Xash3D has it's own crt library. It's recommended to use it. In most cases it's just a wrapper around the standard C library.
* If your feature need platform-specific code, move it to `engine/platform` and try to implement to every supported OS and every supported compiler or at least leave a stubs. * If your feature needs platform-specific code, move it to `engine/platform` and try to implement every supported OS and every supported compiler or at least leave a stub.
* You must put it under appopriate macro. It's a rule: Xash3D FWGS must compile everywhere. For list of platforms we support, refer to public/build.h file. * You must put it under the appropriate macro. It's a rule: Xash3D FWGS must compile everywhere. For list of platforms we support, refer to `public/build.h`.
### Code style ### Code style
* This project uses mixed Quake's and HLSDK's C/C++ code style convention. * This project uses a mix of Quake's and HLSDK's C/C++ code style convention.
* In short: * In short:
* Use spaces in parenthesis, but not when two parentheses are consecutive. * Use spaces in parenthesis, but not when two parentheses are consecutive.
* Only tabs for indentation. * Use only tabs for indentation.
* Any brace must have it's own line. * Any brace must have it's own line.
* Short blocks, if statements and loops on single line are allowed. * Use short blocks, if statements and loops on single line are allowed.
* Prefer generic utilities from libpublic over rolling your own. * Prefer generic utilities from libpublic over rolling your own.
* Avoid magic numbers. * Avoid magic numbers.
* While macros are powerful, it's better to avoid overusing them. * While macros are powerful, it's better to avoid overusing them.
* If you unsure, try to mimic code style from anywhere else of engine source code. * If you are unsure, try to mimic the code style from anywhere else in the engine source code.
* **ANY** commit message should start from declaring a tags, in format: * **ANY** commit message should start from declaring tags, in the format:
`tag: added some bugs` `tag: added some bugs`
`tag: subtag: fixed some features` `tag: subtag: fixed some features`
Tags can be any: subsystem, simple feature name or even just a filename, without extension. The tags can be a:
Just keep them always same, it helps keep history clean and commit messages short. * subsystem
* simple feature name or even just a filename, without the extension.
Just always keep them the same because it helps keep the commit history clean and messages short.
## LLM-based tools usage. ## LLM-based tools usage.
While we wouldn't recommend using any LLM-based (also misleadingly called AI) tools, we understand that they are here to stay. While we wouldn't recommend using any LLM-based (also misleadingly called AI) tools, we understand that they are here to stay.
Whether you're reporting bug or contributing the code, you take complete authorship and responsibility over provided content and the same rules will apply to you as for everybody else, so validate the bug report or the patch before sending it. Whether you're reporting a bug or contributing to the code, you will take complete authorship and responsibility over the provided content, and the same rules will apply to you as for everybody else, so validate the bug report or the patch it before sending it.