Godot code style, project structure and friends

17. August 2025

I started using Godot 3 around 5 years ago. A lot of things changed since then. Godot 4 and GDScript 2.0 are out and I learned a lot about writing better code.

Everything here is covered in the official Godot docs and that is the best place to get the correct and up to date information. Said that, I just will point you to the right place in the docs and add my two cents.

Note: Godot version 4.4.1 is used here, some things might be different in other versions.

Write good code

Everybody can has his own thoughts about what defines good code. But I think we can all agree that maintainability, readability and organization are king. This increase the developer experience and can increase the time of your coding sessions.

Another important key aspect might be performance, but only after the code works and looks good. And never forget done is better than perfect. Endless code style adjustments and refactoring can stop progress.

Project organization

There is a dedicated page in the docs for project organization.

The main takeaway is to create a directory for every scene and put all scripts, assets and scene files there.

I do it a bit different, since most of my games don't have many assets and I also keep track of used licenses for third party assets. So having all assets in a single directory makes it easier to keep track of used third party assets.

This structure crystallized for me over time, but might not work for you. Time will show what is best for you and your projects.

Code style

For the code style the documentation is much more detailed.

I regret not having read this earlier. My first two Godot projects have a horrible code style. But as many times in life, errors are the best teachers. Now I really care about how my code is written and structured. I prefer now to fix things immediately instead of waiting.

I respect now rigidly the code order and made also a bash alias that prints me the order, for easy access. I saw people on reddit printing the code order docs and framing it above the monitors on the wall.

Naming conventions

Also here I didn't follow the official convention for years. Then I had to rename hundreds of files and always follow now the way it should be.

Static typing

Coming from Java with static types I really miss the rigid type checks at compile time. I really recommend using static typing in Godot, for less bugs, better error detection and performance. It also allows to find errors fast, as described in a previous blog post

The docs state that best practice is to always use it or never. Mixing static and dynamic typing is seen as bad practice and can cause confusion.

Scene unique nodes

This is a nice way to keep mental sanity while accessing Nodes in code. I used to drag and drop Nodes into the script editor, while holding Ctrl, to get the full node path. But since I switched to Neovim as my main editor, I cannot do that anymore.

Better, because now I use the Scene unique nodes that allow accessing nodes without writing the full path.

# access by unique name
var label: Label = %Label
# instead of full path
var label: Label = $MarginContainer/VBoxContainer/YetAnotherContainer/Label

This is so much cleaner in the code and most important Nodes can be moved and renamed freely in the scene tree, without breaking the path in the code.

UIDs

Since Godot 4.4 added UID support it is possible to do access script files with their unique UID, instead of the full file path. This brings a similar logic, as we have with unique node names, to script and scene files.

# access by UID
var scene: PackedScene = load("uid://b48hr5ervcv")
# instead of full path
var scene: PackedScene = load("res://src/screens/settings/audio/audio_settings.gd")

With this also files can be moved and renamed freely, without breaking paths in the code.

Linters and formatters

The gdtoolkit is a python tool that provides a parser, linter, formatter and code metrics calculator. I have to admit that I tried the linter and formatter and I didn't like it. At the time, the false positives were simply too many.
If years of JS linters at work taught me one thing, it is that they never work properly ;-) But I will checkout the tool every few months and see if it improved and you should too. Maybe for you it works!

Every feedback is welcome

Feel free to write me an email at info@simondalvai.org and comment on Mastodon.

mastodon button Codeberg button Email button RSS button