AstralTransRocketries/Cubyz
1
0
Fork 0
mirror of https://github.com/PixelGuys/Cubyz.git synced 2025-08-03 03:06:55 -04:00
Code Issues Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md

Browse Source 
as discussed in #1297
This commit is contained in:
IntegratedQuantum 2025-04-19 13:13:09 +02:00 committed by GitHub
parent 332e9f57f0
commit a6ef0dc57e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
CONTRIBUTING.md
View File

@ -61,6 +61,8 @@ Cubyz has two main allocators.
Sometimes it might also make sense to use an arena allocator `utils.NeverFailingArenaAllocator` (when you have many small allocations that share the same lifetime, e.g. assets), or a `MemoryPool` (if you have many items of the same type that get freed and allocated many times throughout the game).
Sometimes it may be useful to use stack buffers when the maximum size is known (e.g. bufPrint), however the stack allocator is usually fast enough, so this should only be done when there is a clear performance benefit. Otherwise it may just cause future problems when the underlying sizes change.
Also it is important to note that Cubyz uses a different allocator interface `utils.NeverFailingAllocator` which cannot return `error.OutOfMemory`. Along with it come some data structures like `main.List` and more in `utils` which should be preferred over the standard library data structures because they simplify the code.
## Free all resources
@ -103,7 +105,7 @@ Otherwise you may just end up with a more complicated and slower thing.
Most of the syntax is handled by a modified version of zig fmt and checked by the CI (see the formatting section above).
There are a few more things not covered by the formatter:
- **Naming conventions:** camelCase for variables, constants (no all-caps constants please!) and functions; CapitalCamelCase for types; snake_case for files and namespaces
- **Naming conventions:** camelCase for variables, constants (no all-caps constants please!) and functions; CapitalCamelCase for types; snake_case for files and namespaces. Abbreviations are treated as one word, e.g. zon/ZonElement instead of ZON/ZONElement.
- **Line limit:** There is no line limit (I hate seeing code that gets wrapped over by 1 word, because of an arbitrary line limit), but of course try to be reasonable. If you need 200 characters, then you should probably consider splitting it or adding some well-named helper variables.
- **Comments:** Don't write comments, unless there is something non-obvious going on that needs to be explained.<br>
But in either case it's better to write readable code with descriptive names, instead of writing long comments, since comments will naturally degrade over time as the surrounding code changes.<br>