From fba10a94c2ce4c57b4a7320d0c636be497312f34 Mon Sep 17 00:00:00 2001
From: IntegratedQuantum <43880493+IntegratedQuantum@users.noreply.github.com>
Date: Mon, 24 Mar 2025 21:30:29 +0100
Subject: [PATCH] Update CONTRIBUTING.md
Add file/namespace name convention
---
CONTRIBUTING.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 79e26aca..87790e3a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -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).
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.
- **Comments:** Don't write comments, unless there is something non-obvious going on that needs to be explained.
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.