In the past, I used to make my code excessively bloated by making a class/struct for most anything and everything. I found this in one of my old projects-
class_name Cell extends Node
var alive = true
func flip():
alive = not alive
Considering how wasteful I was, I’ve decided to do as little OOP as possible. However, looking at my new code, I’ve wondering if my code has gotten worse? Anything I can do to improve it?
There’s not much code here to look at though, is there? Occasionally, people stress out about these things - the answer usually is “don’t”. The first thing you worry about is “Is it working?”, “Are there potential bugs?”, “Are all the cases covered?”, then next “Is it working efficiently?”, and the very last question should be “Does my code look okay?”. Not the other way around. Another matter is when you’re working in a team, but in that case they should have already answered all your questions by providing you with their guidelines.
performance should go after “does my code look okay”. performance is the last thing we have to worry about especially in 2025, and especially in logic.
good code is easier to debug and extend, which covers your first 3.
so:
1 - is it working (most important)
2 - does it look okay
3 - are all the cases covered (helped by good code)
4 - are there potential bugs (helped by good code and all cases covered)
5 - performance (helped by all of the above)
as for rules, you have to follow the gdscript style guide:
following a style is essential in any big enough project, even if you don’t work with other people, it will help you read your own code.
there’s also a best practices page in the documentation:
I would also tell you to read all you can of the documentation so you can learn all the tools and apply them wherever they are best suited. This takes practice and experimentation, but for example, a novice programmer will create a million scenes one for each Control node and button, while an advanced programmer will know about the theme system and use it instead of having to code.
the least you code, the better. use the tools already available unless there is a very good reason why they are not enough. But don’t stop on the small details, if a feature is not essential, you have to leave it and continue, perfectionism is bad because you don’t get stuff done and you waste time.
The style guide is opinion. ALL style guides are opinion.
It could be useful to read it, you can follow some or all of it if you like, but the style guide is nothing but someone else’s opinion of what good GDScript code looks like. If it doesn’t work for you or if some aspect of it isn’t to your liking, ignore it.
Yes, when you’re working with a team you should probably come to an agreement about style, and if you don’t have particularly strong opinions the GDScript style guide is fine. Other styles are fine too, including a style your team evolves towards organically as you decide what you like.
If you’re working on your own, do whatever you like; you can follow the guide completely, partly, or not at all. Format your code however best makes sense to you.
Personally, I’m not a fan of the GDScript style guide; there are several things in it which I consider to be unfortunate choices. For someone else, it might be exactly what they want, or they may like the choices I don’t but have other sections they disagree with. There is no “one true way” to format code, and any set of rules winds up being awkward with some edge cases.
it is official. It’s in the official documentation.
I would argue godot is designed around that guide, the way new features like the new let keyword will be implemented, will be implemented with the official style guide in mind.
I would also argue that some parts of the guide HAVE to be followed when writing code, because godot already works around it, like using snake_case for file names, since these are converted to PascalCase automatically, at least when creating an autoload.
as a programmer, you have to get used to following a style, consistency is VERY important to write code that can be read by other people, and those other people can be yourself 1 month later.
I used to do whatever back when I worked with python, but I’m more experienced now, I know what happens when your project gets past the 12th script and you forget what Box.py does.
sure, but that is different from not following any style at all.
most of the style guide makes practical sense, like keeping your lines below 100 characters, or breaking Dictionary and Array definitions.
others like indentation are designed around making sure the code is understood not just by the engine but by the person reading it.
trailing coma makes your life easier when having to add more items to an array.
I could keep going, but the point is, many of these suggestions are really good.
Without knowing the context in which this code was used, it’s difficult to say if making the class was a ‘waste’ or not. Can I ask what your biggest hang-up about it is? Is it the length? Just because it’s four lines of code doesn’t make it inherently wasteful. Maybe it doesn’t make sense for alive to be a property of a different class. Maybe Cell is a parent to 25 different other classes which all have their own implementation of the flip function. There are perfectly valid reasons to have a tiny class like that.