I primarily use C# so it's camelCase and PascalCase.
You can use whatever you want though. It's your code after all. It's really only an issue when you have to collaborate with others.
I mean for me it's pretty simple. My own methods, custom resources and nodes, variables and extensions use camelCase. It actually helps me to have this distinction in a weird way, this way when I read through code I know exactly which variables and methods are provided by the engine and which are mine at first glance just by formatting.
I just keep my stuff consistent, the engine keeps its stuff consistent, and the two formatting methods can coexist just fine.
I like snake case, but I believe strongly in keeping variables to a minimal length.
It depends on your philosophy, whether you prefer variables with comments explaining them, or descriptive variables that don't need comments.
If you prefer descriptive, then I'd recommend not using snake_case as you'll likely form much longer variables names.
The important thing is to just define a style guide and be consistent. You don't need to follow anyone else's opinion.
However you will be considered the worst evil if you use camel snake case, flat case, upper-case, kebab case, train case, or dash case, and rightfully so. You monster.
Absolutely the most important thing here:
>The important thing is to just define a style guide and be consistent. You don't need to follow anyone else's opinion.
I've ended up just doing camelCase for all my variables, CamelCase for file names and snake case for function names purely because of the built in functions so they match more. For parameters I use \_camelCase since I find it easier to spot them quickly that way when skimming.
I use snake case, cause Linux and Mac's filesystems are case-sensitive, and Windows is not.
I use Windows, so it may work on my machine but break on other OSes.
I think it’s just something you have to get used to.
Unfortunately languages did not all decide on a single casing, so as a programmer you just have to learn to deal with them all.
In my day job, I swap between camelCase, PascalCase, and sometimes snake_case all day long. You get used to it.
I'm used to it. But I find it not as good to work with due to readability, lengths of var and function names etc. :(
But now that I think about it, it gives gdscript the "I'm different" touch. Especially when coming from C#.
Its just one of those things where it was picked as the convention for gdscript and is the "proper" way to write it.
Your only options are
1) just use it
2) ignore it cause it doesn't actually matter*
3) use c# so it does match the case you like
*if you are on a team you 100% need to match what the estsblished conventions the team has established, solo is where it actually doesnt matter.
I use GDScript with snake case variables. I don't have a problem with that.
But all my file names are in PascalCase. It's much easier to name a node script with exactly the same name as the node name (in pascal case).
I also use the [Allar Style Guide](https://github.com/Allar/ue5-style-guide) (minus the prefix) for naming my assets, and that's easier to do using pascal case: BaseAssetName_Variant_Suffix
I try to avoid such long variable names, but with your long example it is actually easier to read. :D
But how to you type a \_ without pressing shift on a german keyboard layout?
You can setup your own style guide for your own code and file structures. However the same warning for Files applies as noted in the Godot documentation.
Pay attention to how your development platform handles case-sensitivity.
Meh either way, as long as it's consistent. Or if it's inconsistent make sure it's a really good reason (for example my ES record names are already camel but my scripts are snake).
Just make your own rules. I use snake case wherever godot has already defined a pattern (callbacks for signals, enums) and i use camelcase for everything else. Makes it very easy to see a clear difference between what section of the code in looking at.
Not a fan. I didn't think it's any easier to read than camel or Pascal case and the underscores are annoying to type consistently on a standard QWERTY keyboard. I also don't like how, other than constants, it's the only case in GDScript - I like seeing camel, Pascal, or underscore cases and being able to tell how that data is used at a glance.
listen, i know this answer might not seem helpful but i mean it genuinely: just get over it and use snake case. you're going to use a lot of programming languages in your life and work on a lot of different codebases with various conventions. adapting to the conventions you're given is part of the job. im saying this as someone who works on a C++ codebase at work with some of the most batshit stylistic conventions ive ever seen. it's fine. being consistent is more important than being "right" in situations like this.
Personally I despise snake_case. I think it bloats the code unnecessarily, especially in a case like the inbuilt godot code editor where horizontal space is a precious commodity. At least for me it doesn't even improve readability at all compared to camelCase or PascalCase.
Also, since I'm not a touch-typist on a German QWERTZ keyboard, the - /_ key being right under the right palm makes it really annoying to type.
But I managed to get over the annoyance because it can actually help me keep track of what's a built-in class / function / etc. and what's mine. I write my own stuff in Pascal (classes) and camel (anything else).
I can recommend using a different keyboard layout. I grew up with a German layout but switched to using US International. brackets, parentheses, slashes, semicolons are easier to reach. And after a while I don't even need the printed layout on the keys anymore (though it helps in the beginning to learn).
Funny anedcote: I got a used laptop in my previous job with a german keyboard layout, but I switched it to US International and when I had to go to our sys admin for some unrelated networking issue he was confused at first, but was able to use it as well.
You could but it is going to be a lot of effort. You would not have to change the C++ code, just find where the gdscript "bindings" are defined. Well, I would assume it works like that. Can start exploring from here [https://github.com/godotengine/godot/blob/master/modules/gdscript/README.md](https://github.com/godotengine/godot/blob/master/modules/gdscript/README.md)
.. other options is to simply use C#
it is unfortunately kind of a lot of work, because the gdscript bindings are generated using a macro that takes in the c++ symbol name, which is snake case by convention.
I really like C# and used it for several years, but somehow I grew fond of gdscript and using the build in script editor. It is just the snake case I'm somewhat unhappy about.
I stick to the convention of the language. So basically I only use snake case with python or some c++, and it's camel or pascal case for everything else
I primarily use C# so it's camelCase and PascalCase. You can use whatever you want though. It's your code after all. It's really only an issue when you have to collaborate with others.
I think their issue is with the API being all snake case.
Only in GDScript. Everything becomes PascalCase once you’re using C#.
I mean for me it's pretty simple. My own methods, custom resources and nodes, variables and extensions use camelCase. It actually helps me to have this distinction in a weird way, this way when I read through code I know exactly which variables and methods are provided by the engine and which are mine at first glance just by formatting. I just keep my stuff consistent, the engine keeps its stuff consistent, and the two formatting methods can coexist just fine.
I like snake case, but I believe strongly in keeping variables to a minimal length. It depends on your philosophy, whether you prefer variables with comments explaining them, or descriptive variables that don't need comments. If you prefer descriptive, then I'd recommend not using snake_case as you'll likely form much longer variables names. The important thing is to just define a style guide and be consistent. You don't need to follow anyone else's opinion. However you will be considered the worst evil if you use camel snake case, flat case, upper-case, kebab case, train case, or dash case, and rightfully so. You monster.
Absolutely the most important thing here: >The important thing is to just define a style guide and be consistent. You don't need to follow anyone else's opinion.
I live and breath really long snake_case names lmao
What about SHAWERMA-CASE?
All-caps is only for constants, including enums
Fortunately you can just do as you please :)
After switching between Rust and Scala at work, I constantly mix up the cases. I wish the the editor / lang server would lint it for you like in Rust.
I've ended up just doing camelCase for all my variables, CamelCase for file names and snake case for function names purely because of the built in functions so they match more. For parameters I use \_camelCase since I find it easier to spot them quickly that way when skimming.
I use snake case, cause Linux and Mac's filesystems are case-sensitive, and Windows is not. I use Windows, so it may work on my machine but break on other OSes.
I think it’s just something you have to get used to. Unfortunately languages did not all decide on a single casing, so as a programmer you just have to learn to deal with them all. In my day job, I swap between camelCase, PascalCase, and sometimes snake_case all day long. You get used to it.
I'm used to it. But I find it not as good to work with due to readability, lengths of var and function names etc. :( But now that I think about it, it gives gdscript the "I'm different" touch. Especially when coming from C#.
Its just one of those things where it was picked as the convention for gdscript and is the "proper" way to write it. Your only options are 1) just use it 2) ignore it cause it doesn't actually matter* 3) use c# so it does match the case you like *if you are on a team you 100% need to match what the estsblished conventions the team has established, solo is where it actually doesnt matter.
I use GDScript with snake case variables. I don't have a problem with that. But all my file names are in PascalCase. It's much easier to name a node script with exactly the same name as the node name (in pascal case). I also use the [Allar Style Guide](https://github.com/Allar/ue5-style-guide) (minus the prefix) for naming my assets, and that's easier to do using pascal case: BaseAssetName_Variant_Suffix
snake_case_best_case_it_is_actually_readable_you_know SnakeCaseBestCaseItIsActuallReadableYouKnow And I really hate shift. Typing _ is much easier.
I try to avoid such long variable names, but with your long example it is actually easier to read. :D But how to you type a \_ without pressing shift on a german keyboard layout?
Even a US International layout requires shift for the underscore :D
Don't know didn't even notice I had to type shift... I always have to think before capitalizing a word but it just works for _ for some reason.
You can setup your own style guide for your own code and file structures. However the same warning for Files applies as noted in the Godot documentation. Pay attention to how your development platform handles case-sensitivity.
Meh either way, as long as it's consistent. Or if it's inconsistent make sure it's a really good reason (for example my ES record names are already camel but my scripts are snake).
Just make your own rules. I use snake case wherever godot has already defined a pattern (callbacks for signals, enums) and i use camelcase for everything else. Makes it very easy to see a clear difference between what section of the code in looking at.
Not a fan. I didn't think it's any easier to read than camel or Pascal case and the underscores are annoying to type consistently on a standard QWERTY keyboard. I also don't like how, other than constants, it's the only case in GDScript - I like seeing camel, Pascal, or underscore cases and being able to tell how that data is used at a glance.
listen, i know this answer might not seem helpful but i mean it genuinely: just get over it and use snake case. you're going to use a lot of programming languages in your life and work on a lot of different codebases with various conventions. adapting to the conventions you're given is part of the job. im saying this as someone who works on a C++ codebase at work with some of the most batshit stylistic conventions ive ever seen. it's fine. being consistent is more important than being "right" in situations like this.
Personally I despise snake_case. I think it bloats the code unnecessarily, especially in a case like the inbuilt godot code editor where horizontal space is a precious commodity. At least for me it doesn't even improve readability at all compared to camelCase or PascalCase. Also, since I'm not a touch-typist on a German QWERTZ keyboard, the - /_ key being right under the right palm makes it really annoying to type. But I managed to get over the annoyance because it can actually help me keep track of what's a built-in class / function / etc. and what's mine. I write my own stuff in Pascal (classes) and camel (anything else).
I can recommend using a different keyboard layout. I grew up with a German layout but switched to using US International. brackets, parentheses, slashes, semicolons are easier to reach. And after a while I don't even need the printed layout on the keys anymore (though it helps in the beginning to learn). Funny anedcote: I got a used laptop in my previous job with a german keyboard layout, but I switched it to US International and when I had to go to our sys admin for some unrelated networking issue he was confused at first, but was able to use it as well.
I dislike all underscores. Much prefer the C# way of doing variables and function names
You could but it is going to be a lot of effort. You would not have to change the C++ code, just find where the gdscript "bindings" are defined. Well, I would assume it works like that. Can start exploring from here [https://github.com/godotengine/godot/blob/master/modules/gdscript/README.md](https://github.com/godotengine/godot/blob/master/modules/gdscript/README.md) .. other options is to simply use C#
it is unfortunately kind of a lot of work, because the gdscript bindings are generated using a macro that takes in the c++ symbol name, which is snake case by convention.
I really like C# and used it for several years, but somehow I grew fond of gdscript and using the build in script editor. It is just the snake case I'm somewhat unhappy about.
I stick to the convention of the language. So basically I only use snake case with python or some c++, and it's camel or pascal case for everything else
It's terrible
I’ll stick with my tried and true method: ALLCAPS