Skip to content
This repository was archived by the owner on May 8, 2022. It is now read-only.

Code style

ChickenStorm edited this page Aug 23, 2020 · 10 revisions

Code style

As a general rule follow the official style guide. However the code order between 12 and 16 are not strictly followed.

Accessing children

the best way to get a node is to call the function using $path instead of get_node("path") however it is not possible to use node.$path as $path is a literal. It is also a good practice to use

onready var node = $path

There there is however a few inconveniences, let us compare some code. Assume that we have a scene

Root
 |--Children
    |-- GrandChildren
    

where GrandChildren has a property number we want root to have a property number and update the GrandChildren's number when root's number is changed

Code 1:

extends Node

export(int) number = 0 setget set_number

onready var grand_children = $Children/GrandChildren

func _ready():
    _update_nodes()


func set_number(new_number):
    number = new_number
    _update_nodes()


func _update_nodes():
    if grand_children != null:
        grand_children.number = number

this should be the most common code used. It has the advantages that it is easy to change the structure of the scene with minimal change in the code and that it still works. The inconvenience is that grand_children is only available after the node is ready meaning that we need to check that it is not null and in _ready() we need to call _update_nodes().

Code 2:

extends Node

export(int) number = 0 setget set_number

onready var children = $Children

func _ready():
    _update_nodes()


func set_number(new_number):
    number = new_number
    _update_nodes()


func _update_nodes():
    if children != null:
        children.get_node("GrandChildren").number = number

This is similar of code 1. However we acces the grand children trough children. This can be more useful over code 1 if you have a large structure under children and you know that the structure under children won't be change but that above children the structure might change in that case only the path to get to children has to be changed. That case is however rare. The other case is if GrandChildren is not in the packaged scene but added by the code and its name change.

Code 3:

extends Node

export(int) number = 0 setget set_number

func _ready():
    pass


func set_number(new_number):
    number = new_number
    _update_nodes()


func _update_nodes():
    $Children/GrandChildren.number = number

This code style is rarer as we prefer code 1. This code can be however useful if the code inside the node is sufficiently small or the structure won't change. The advantage is that inside a packaged scene we can access the descendant node just after the initialization. Therefore a check whether the literal is null is not necessary (if you are sure that the node is inside the packaged scene or is initialized in _init()), we do not need to update the node on ready. However the disadvantage is that it become harder to change the structure of the scene as every call to the literal has to be changed. It is advise to use it sparely and prefer the style of 1 for larger node.

Communication between node

If a node wants to communicate with one of its descendant the code inside the node can just call a method of the descendant. Otherwise it is best to use signals. If the game state is changed it is best to us the Store to modify the data and emits a signal.

Wiki

home

Repository and contributing

Game

Architecture

Game element

Good practice

Clone this wiki locally