Closed fenix-hub closed 3 years ago
In order to follow the (official) GDscript style guide, major and minor refactoring will be accomplished.
Major refactoring:
Regarding addons/godot-firebase/
folder structure, naming conventions for functions.
└ godot-firebase/
└ auth/
└ containers/
└ database/
└ firebase/
└ firestore/
└ storage/
└ plugin.gd
PrefixSuggix
format, where Prefix
is Firebase and Suffix
is the relative component name, with the PascalCase naming.
solution: Once files will be foldered in their own modules, this naming convention won't be needed anymore. Instead, each file will be named referencing just the components it represents, with a snake_case convention. Thus, single files will be recognized by their path and, in case they are scripts, they will be identified by a unique class name.
example:
└ auth/FirebaseAuth.gd -> auth/auth.gd (with FirebaseAuth as class_name)
└ auth/FirebaseUserData.gd -> auth/user_data.gd (with FirebaseUserData as class_name)
[...]
└ firestore/FirebaseFirestore.gd -> firestore/firestore.gd (with FirebaseFirestore as class_name)
└ firestore/FirebaseFirestoreCollection.gd -> firestore/collection.gd (with FirebaseFirestoreCollection as class_name)
└ firestore/FirebaseFirestoreDocument.gd -> firestore/document.gd (with FirebaseFirestoreDocument as class_name)
Minor changes:
Code order, as suggested in the GDscript style guide:
tool
class_name
extends
signals
enums
constants
exported variables
public variables
private variables
onready variables
optional built-in virtual _init method
built-in virtual _ready method
remaining built-in virtual methods
public methods
private methods
Function, variables and constants' name following private/public naming convention
Define parameters and variables type in each script
Comment functions
Align code style with the official GDScript style guide.
This will make the plugin more consistent, giving the main dev team (us) and future contributors a common style more than practices, without changing our way to code but just how it is presented through APIs.
note: heavy refactoring based on files' names and foldering, without changing functionalities or structure.