StarOpenSource/CORE
StarOpenSource/CORE
2
0
Fork 0
Code Issues Pull requests Releases 1 Activity

Fix typo and writing

Browse source
This commit is contained in:
JeremyStar™ 2024-04-25 17:30:20 +02:00
parent 3c1935c9e9
commit 53981c55f9
Signed by: JeremyStarTM
GPG key ID: E366BAEF67E4704D
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/docs/guides/custom-modules.md
View file

@ -10,13 +10,13 @@ Custom modules in CORE are special scripts that run inside and interact with the
Before you write any code, you should decide wheneter to write your code as a module or as a simple script. Generally you **not** write everything used between two classes as a module. Use custom modules for stuff you may want to use across multiple objects or need to use frequently in your codebase. One example of this is a transition script. You'll probably want to transition from one scene to another in a game quite often, writing it as a custom module makes much more sense as it can be accessed globally much easier and can be shared across codebases. Before you write any code, you should decide wheneter to write your code as a module or as a simple script. Generally you **not** write everything used between two classes as a module. Use custom modules for stuff you may want to use across multiple objects or need to use frequently in your codebase. One example of this is a transition script. You'll probably want to transition from one scene to another in a game quite often, writing it as a custom module makes much more sense as it can be accessed globally much easier and can be shared across codebases.
## Bad practise ## Bad practise
Before we finally come to some code, never write a custom module if you intend to do the following: Before we finally come to some code, never avoid these things while writing a custom module:
- Access hardcoded classes, scripts, assets, etc. from your project. Use arrays and dictionaries aswell as get(), set() and other functions for that. - Access hardcoded classes, scripts, assets, etc. from your project. Use arrays and dictionaries aswell as get(), set() and other functions for that.
- Depend on your project code. Modules are intended to be project independent and work in every environment where CORE runs. - Depend on your project code. Modules are intended to be project independent and work in every environment where CORE runs.
- Never crash the entire framework on invalid user input, only crash when an internal error occurred. \ - Never crash the entire framework on invalid user input, only crash when an internal error occurred. \
Let's say that you have two functions: An internal `_display_scene` method and a `transition_between_scenes` method. \ Let's say that you have two functions: An internal `_display_scene` method and a `transition_between_scenes` method. \
When the developer calls `transition_between_scenes` and supplies an invalid object to the method, you should call `logger.error` (and return the error) as the error comes from the developer and should be handled by the developer's code. \ When the developer calls `transition_between_scenes` and supplies an invalid object to the method, you should call `logger.error` (and return the error) as the error comes from the developer and should be handled by the developer's code. \
If however your `transition_between_scenes` calls `_display_scene` and supplies an invalid transition type, you should call `logger.crash` instead as your module code as an inconsistency and may not account for that. This ensures your code does not do stupid things *plus* you get a bug report or pull request from an annoyed developer :) If however your `transition_between_scenes` calls `_display_scene` and supplies an invalid transition type, you should call `logger.crash` instead as your module code has an inconsistency and may not account for that. This ensures your code does not do stupid things *plus* you get a bug report or pull request from an annoyed developer :)
- Never create, instantiate or duplicate objects without removing them from the SceneTree and freeing them first. This ensures no memory leaks occur and makes your codebase a bit better. \ - Never create, instantiate or duplicate objects without removing them from the SceneTree and freeing them first. This ensures no memory leaks occur and makes your codebase a bit better. \
If you wonder how to do this, look at CORE's logger. It frees unused `CoreLoggerInstance`s every time CORE's scheduler (`_schedule`) is executed and frees *all* `CoreLoggerInstance`s on framework cleanup (`_cleanup`). If you wonder how to do this, look at CORE's logger. It frees unused `CoreLoggerInstance`s every time CORE's scheduler (`_schedule`) is executed and frees *all* `CoreLoggerInstance`s on framework cleanup (`_cleanup`).
- Not defining variable and method return types. Forcing a variable to match a `String` or a method to always return an `int` ensures your code always runs without flaws and invalid user input, saving you a few bugs while improving code quality. If a variable may contain or a method may return multiple types, use `Variant` for everything but objects and `Object` for everything that is an object. - Not defining variable and method return types. Forcing a variable to match a `String` or a method to always return an `int` ensures your code always runs without flaws and invalid user input, saving you a few bugs while improving code quality. If a variable may contain or a method may return multiple types, use `Variant` for everything but objects and `Object` for everything that is an object.