You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+14-8Lines changed: 14 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,22 +31,28 @@ After submitting your pull request, I (MewPurPur) will review your changes and m
31
31
32
32
Editing translations is explained [here](translations/README.md)
33
33
34
-
## Code guidelines
34
+
## Code guidelines and style
35
35
36
-
To document some quirks of our code that we've decided on:
36
+
As usual, look around and try to copy the things you find in surrounding code.
37
37
38
-
- StringNames are avoided when possible. We do this because it makes the codebase simpler, although if something is actually shown to be performance-critical, it can be reconsidered.
39
-
- Nodes may only be exported if their runtime structure isn't known.
38
+
Guidelines:
39
+
40
+
- StringNames are avoided when possible.
41
+
- Rationale: This makes the codebase simpler, and StringNames aren't a universal optimization. I've heard of a lot of cases where they counterintuitively make performance worse, and I don't currently understand them well-enough to not fall into traps. If performance benefits for using StringName somewhere are arduously benchmarked, it can be considered.
42
+
- We avoid exporting nodes, unless their runtime structure isn't known.
40
43
- Strings are always translated with `Translator.translate()`, not `tr()`.
41
44
42
-
## Code style
45
+
Follow the [GDScript style guide](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html). Almost all this guide's rules are enforced here.
43
46
44
-
For scripts, only GDScript code is allowed. Follow the [GDScript style guide](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html). Most of its rules are enforced here. Additionally:
47
+
We have some additional style rules:
45
48
46
-
-Static typing is used as much as possible.
49
+
-Always use static typing. And if possible, use inferred typing, i.e., `var f := 4.0` instead of `var f: float = 4.0`
47
50
- Comments are typically written like sentences with punctuation.
48
-
- Two spaces are used to separate inline comments and code.
51
+
- Inline comments are separated from the code by two spaces.
52
+
- Documentation comments are written like normal comments, without modifiers like `[param]` or `[code]`.
53
+
- Rationale: The amount by which they improve the readability of the documentation isn't enough to outweigh how much worse they are when you look at them in code. I believe they aren't suitable in a project where only developers will be reading them.
49
54
- For empty lines in the middle of indented blocks, the scope's indentation is kept.
55
+
- Rationale: I don't really know why this isn't conventional, I find that it just gets in the way when you want to add code where there were previously empty spaces.
50
56
- Class names use `class_name X extends Y` syntax.
51
57
52
58
Don't make pull requests for code style changes without discussing them first (unless it's for corrections to abide by the ones described here). The same generally applies to making style changes unrelated to a PR's main goal. Pull requests may also get production tweaks to tweak their style before being merged.
0 commit comments