Copy LinkCopied!Side Effect

We say that a function has side effects when it changes in the state of the program. This includes any action your code performs that affects data outside of the function itself, like:

• Modifying global or member variables.
• Writing to files or databases.
• Listening to player input.
• Printing to the Output bottom panel in Godot, to the terminal, or logging operations.
• Making network requests.
• Modifying other objects. For example, updating the user interface.
• Interacting with hardware. For example, drawing things on the screen.
• Throwing exceptions or errors (GDScript doesn't have this feature, though).

Side effects make changes in the program's data harder to track. They're error-prone because different parts of the code can end up modifying the same data, leading to unexpected results.

For that reason, it is considered a general good practice to avoid too many side effects in your code and make side effects explicit when possible. Proponents of functional programming, a programming paradigm, will enforce a style where as many functions as possible are pure. In this style, if there are errors in the code, they are easier to track down because the functions are isolated and don't depend on external data. Programs with the functional programming style still have side effects, but they're isolated and reduced to a minimum.

In games, this is often not possible, as games need to respond to player input and constantly update the game world accordingly. Plus, they need to do that fast. So, we tend to follow different programming styles. For example, Godot and GDScript are primarily imperative and object-oriented, like most game engines. In the imperative paradigm, we write instructions that the computer follows step by step. In the object-oriented paradigm, we organize our code around objects that have properties and methods.