Confusing _ (underscore) for private, virtual, signals, callbacks, lifecycle functions #19209
Comments
|
Also mentioned here #14466 |
|
When you consider that nothing is really private in GDScript, the underscore is quite pointless. It can be an internal convention for users to make in their method names, but engine provided methods don't really need to be marked this way (and considering that they are called by the engine itself, they should be considered public anyway). As said, it's not used consistently, so much that many contributors got it wrong, which made it more inconsistent. If it were up to me I would remove the underscore prefix from everything. For the hidden methods and properties I think it's okay though. They don't show up in docs and aren't supposed to be called from the scripts anyway. |
|
The way I always understood it is that any functions that could be considered responding to a signal/event (ready, input, physics process, on button pressed, etc.) should be prefixed with a I am curious if you have any suggestions on how to better categorize the functions, though. |
|
@LikeLakers2 yea when using just the engine I got the same impression than u. My proposal would be to rename all virtual, (auto-called function) to |
|
isn't this a python-ish convention like PEP8 or something?? When you name a function which shouldn't be called outside a class, i.e. private, you add _ to its beginning. I don't know how it is on the source code, but in the API it seems consistent to me. I mean, if you are connecting a notification to a method, this method should be called by the notification only, shouldn't it? I mean, you can get a pretty hard time debugging a method that is called both by a built-in notification (signal) and by a custom method. And for lifecycle functions it makes even more sense...is not recommended at all to call Since GDScript, as Python, doesn't have As for the core, Since C++ has such scopes, I think they are only using this convention for user exposed methods, is this the case? PS: just pointing out that is not something exclusive for virtual functions or anything, it is a convention for "telling" that a method is meant to be considered |
|
Well, you're not supposed to call For In any case, there's no consistency at all. If the underscore convention is really useful, there should be a clear documented rule to apply it, otherwise each one thinks it's something different and it loses the meaning. |
|
If the criteria is that virtual functions start with underscore, here's a list of violations: And here's the ones that adheres to it: |
|
So should we do something about it? add a underscore to all of them? |
|
I think it's worth considering removing them entirely (including methods like |
|
I definitely advocate going through those compatibility breaking changes. I still prefer giving virtual functions (those which are bound with: |
|
I also prefer having the underscores present for "virtual" concepts, but the inconsistencies need to be cleared, so I'd rather just add underscores to everything virtual that doesn't yet have it. If a method with an underscore is exposed to the scripting API, but isn't supposed to be called (like the import thing vnen mentioned), then why don't we just not make them visible in the scripting API? It would also be nice if we could specify whether a method is virtual (intended to be overridden) vs. private (intended not to be called externally) in user-defined script functions, but I suspect that will be a task for #20318. |
|
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine. The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker. If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance! |
The current function naming api is confusing in it's _ use.
In the engine source (C++) it is used for the private functions. And in godot it is obviously used for lifecycle callbacks like
_ready(d)or_input(d)but it is also used when creating signal connections via the editor_on_button_pressed().But for builtin api's this is not always the case. There are a lot of virtual functions which can be overwritten by gdscript and are treated like callbacks which don't have a _ (underscore).
Example: editorImportPlugin
all the
get_...methods which are basically callbacks (virtual functions) don't use the _ syntax.The text was updated successfully, but these errors were encountered: