Skip to content

Instantly share code, notes, and snippets.

@RootKiller
Last active October 16, 2024 11:12
Show Gist options
  • Save RootKiller/f22503a916a5a6b9d98ce7024d194e0b to your computer and use it in GitHub Desktop.
Save RootKiller/f22503a916a5a6b9d98ce7024d194e0b to your computer and use it in GitHub Desktop.
This is version of my coding guidelines for Godot projects.

Code Guidelines

The project is written in GDscript - the main scripting language of the Godot Game Engine.

We are following the general principles of writing scripts in Godot. However, there may be some subtle differences - so reading this document is mandatory for anyone who would want to write code for the project.

The guidelines were gradually created, so some source code that do not follow them may still exist. If you find it, fix it.

Style Guidelines

  • Use tabs with a size of 4.
  • Minimize the amount of dead whitespaces.
  • Use snake_case for identifiers.
  • Private identifiers - properties, methods, should begin from underscore. E.g.
var _property: bool = true

func _on_event():
    _property = true
  • For constants use UPPER_SNAKE_CASE
  • For types - classes, enums use PascalCase
  • Dictionary keys should use snake_case
  • Use static typing everywhere.
  • When static typing, use following syntax.
var variable: Type

func method(parameter: Type) -> ReturnType:
    pass
  • Prefix unused variables with underscore.
  • Put property annotations on the same line as the variable.
@export var player_color: Color = Color.YELLOW_GREEN
  • Put all other annotations in a new line.
@tool

@export_category("Category")
@export var my_property: bool = false
  • Use following syntax when using class_name + extends
class_name Player extends IKCC
  • Following this order when declaring properties
    1. Exports
    2. Public
    3. Private
  • Follow this order when declaring methods
    1. Public
    2. Private

In-Code Documentation

While in-code documentation is not required for everything there are some general guidelines:

  • Non trivial code MUST BE documented.
    • This is in the interest of the person writing the code, do not fool yourself you will remember all the details later.:
  • Use ## comments for types, methods, properties etc for them to show in editor (for example in inspector).
  • It is recommended to add a short paragraph at the top of the file to describe the purpose of the script. For example
## Main class of player character.
## It is responsible for handling input and passing it to individual components of the player.
class_name Player extends IKCC

signal on_money_changed(current_balance: int, delta: int)
# ...
  • Methods documentation is also OK
## Set current player state depending on whether they are riding vehicle, or on foot.
func _set_exploration_state():
  • Properties too
## Additional offset that will be applied to the collision object relative to mesh center.
## Used only when world_collision_shape is specified.
@export var world_collision_shape_offset: Vector3

Exceptions

The things that do not have to follow the code style.

  • Addons that are not created by us.
  • Code that relies on types that are only available in the editor can use dynamic typing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment