one quick question, as I understand that _physic_process (or _process) is update on eveyframe, if we define "velocity" inside. is that mean it will repeats to define "velocity" everytime when the frame updated?
does it effect the performance?
In short, this is negligible when it comes to performance. You'll find some more insights below.
Why use local variables
You use locally scoped variables to avoid exposing them and, as your code complexity grows, avoid changing variables in unexpected ways, which is the source of so many bugs in computer programs.
A lot of the way we show you how to code has more to do with keeping your code readable, flexible, or bug-free if possible than making it fast.
Most of the time, this has a negligible impact on performance. That is, even now with GDScript that has little to no optimizations, like Python (at least the version you download on python.org).
This is because the really heavy operations, the loops that do thousands of things every frame happen inside the Godot engine, through code you call from GDScript. And that code is written in fast, compiled C++.
How to know if something matters for performance
The key rule about performance is it's something you must measure in your game. If the game slows down or you measure a given function call takes a lot of calculation time, then you have something impacting performance.
If, however, the game always runs at 60 FPS, you don't have a problem.
There's a tool built into Godot to measure performance: the profiler.
We wrote a guide on Godot's profiler: https://www.gdquest.com/tutorial/godot/gdscript/optimization-measure/
Here's another guide about leveraging Godot's built-in code for performance: https://www.gdquest.com/tutorial/godot/gdscript/optimization-engine/
There's no garbage collector in GDScript so no issue in that regard.
its kinda common sense in dev yeah so why do differently?
I don't think there's a common-sense or best practice that holds true across programming languages regarding the scope of your variables.
In Python, for instance, a garbage-collected language by default, people tend to use local variables as much as possible for readability, and, same as I explained above, to limit unwanted access. Unexpected changes in variables being the primary source of bugs in code - the smaller your variables' scope, the less unexpected accesses you risk.
Also, performance-wise, in Python, local variables offer the fastest lookup speed for the compiler so you can't really say global variables lead to faster programs than local ones. However, you can say for sure they lead to more bugs.
GDScript works a bit similar, without the garbage collector.
Note that here, to me, we're discussing a really small detail in any case.
I'm seeing a lot of inconsistencies and issues with Godot 2D Secrets that make me wonder...
What are the many inconsistencies and issues you found?
My apologies, I just read the Design Patterns in Godot lesson and learned GDScript is not a garbage collector language. Realized I'm being and idiot jumping to conclusions sorry! Deleted my comment.
I'll now reserve my feedback for until I complete the course. I'm happy to be supporting such a project, and thank you for your response!