GodotNuts / GodotFirebase

Implementations of Firebase for Godot using GDScript
MIT License
532 stars 76 forks source link

Align code style with the official GDScript Style Guide #54

Closed fenix-hub closed 3 years ago

fenix-hub commented 3 years ago

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.

fenix-hub commented 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.

  1. The current folder structure consists of in a single folder which contains unorganized files, regarding singletons, single-instance, modules, scripts and scene. Keeping this structure will lead to an inconsistent plugin folder, further complicating the module logics we will eventually apply (following the lines of Firebase suggestions and project examples, ex: firebase/quickstart-unity) and the possibility to extend the plugin itself with additional resources and functionalities, increasing the disorganization for the dev-team and future contributors. solution: the folder structure will be re-designed, following both naming conventions suggested by the GDscript style guide, and a modular approach compliant with the Firebase project and functionalities. example:
    └ godot-firebase/
    └ auth/
    └ containers/
    └ database/ 
    └ firebase/ 
    └ firestore/ 
    └ storage/
    └ plugin.gd
  2. In order to recognize files inside the project, each single file has been name following the 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:

  1. Code order, as suggested in the GDscript style guide:

  2. tool

  3. class_name

  4. extends

  5. docstring

  6. signals

  7. enums

  8. constants

  9. exported variables

  10. public variables

  11. private variables

  12. onready variables

  13. optional built-in virtual _init method

  14. built-in virtual _ready method

  15. remaining built-in virtual methods

  16. public methods

  17. private methods

  18. Function, variables and constants' name following private/public naming convention

  19. Define parameters and variables type in each script

  20. Comment functions