Add naming convention for engine internal nodes and metadata

[dalexeev]

• Add support for internal nodes godot#30391

Some of the engine's internal nodes have friendly names, while others are left with auto-generated names. I remember seeing a comment from one of the maintainers that friendly node names are desirable (although it was about editor nodes).

godotengine/godot#30391 adds an optional include_internal parameter to many methods, but not to get_node. Therefore, if we decide to give friendly names for internal nodes, then we need a naming convention for them.

Also, not all internal nodes have getters like ScrollContainer.get_h_scroll_bar. If we decide to leave it as it is, then it would be nice if all the internal nodes of a node had friendly deterministic names.

• Refactor Object metadata godot#59452

Metadata names starting with _ are not displayed in the editor. However, this may be required not only by the engine, but also by custom code and/or plugins. A naming convention would avoid name collisions.

Suggestion: add naming convention engine internal nodes and metadata. For example, names that start with the _gd_ prefix are considered reserved for the Godot Engine.

Some conventions are already in use, but I haven't compiled a complete list of engine metadata, so I'm not sure if _edit_*_ names are used everywhere.

metadata/_edit_horizontal_guides_ = [48.0, 108.0]
metadata/_edit_vertical_guides_ = [128.0, 224.0]
metadata/_edit_use_anchors_ = true

[Calinou]

I believe this is already tracked by #1018.

[aaronfranke]

That's about the editor nodes (the nodes used to make the editor UI), not the internal nodes the user has access to for their own projects (like GraphEdit's internal nodes).

[Geometror]

Small summary of the discussion over at godotengine/godot#76563:

• Some argued that it would make the scene tree more readable and therefore aid in debugging
• Those users who are aware of the risks of accessing internal nodes directly could benefit from human-readable node names, since they don't have to get the nodes by indices (the risks being that they can be changed at any time, effectively breaking their code, even between maintenance releases)
• Some argued that human readable names might encourage more users (especially those who would be fine using the normal API) to rely on them and avoid the designated API
• It has been pointed out that it would effectively expand the API surface without any clear use cases

The suggestions gaining the most acceptance were:

• Use the @ symbol for names of internal nodes as it's currently used for the auto-generated node names, e.g. @@ConnectionLayer
  • We'd need to use _set_name_nocheck() for that
• Use an explicit and verbose prefix like _INTERNAL_ (maybe combined with @)

[Please let me know if I overlooked an important point, got something wrong or you think something is depicted in a biased way]

My opinion:
I don't think having human readable names for internal nodes really expands the API surface. There is no documentation about it, you still have to find out these names yourself by digging through the scene tree. At this point, it should be clear to you that this is not the intended way to use a Node (having a prefix like the ones suggested above acts as another warning flag).
IMO it's inconvenient/alerting enough so that there is no real encouragement to avoid the API just by descriptive names alone (but I know, that's kind of speculative).
Of course there might be such an effect, but I think the benefit of the improved comprehensibility/aid in debugging (both editor and application) outweighs that.