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

Update CONTRIBUTING.md

Browse Source 
Add file/namespace name convention
This commit is contained in:
IntegratedQuantum 2025-03-24 21:30:29 +01:00 committed by GitHub
parent 005fb6a3aa
commit fba10a94c2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CONTRIBUTING.md
View File

@ -87,7 +87,7 @@ Often the simplest code is easier to read, easier to maintain and more efficient
Most of the syntax is handled by a modified version of zig fmt and checked by the CI (see the formatting section above). 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: 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 - **Naming conventions:** camelCase for variables, constants (no all-caps constants please!) and functions; CapitalCamelCase for types; snake_case for files and namespaces
- **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. - **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> - **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> 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>