godot: Inconsistent type styling in Godot editor

It’s not a matter of engine devs, it’s very common in most programming languages that primitive types are identified as such with their case, as they typically have properties which different from non-primitive types (passing by value vs reference, copy/clone, etc.).

For example, C# uses PascalCase for classes but its primitive types bool, float, int are lowercase.

Another example: Rust primitive data types are lowercase: https://learning-rust.github.io/docs/a8.primitive_data_types.html But it’s non-primitive data types (e.g. structs, enums) are PascalCase. In Godot, types like Vector3 or Color are not primitive data types (they’re collections of primitive data types, here float) and in a language like Rust, they’d typically be represented by structs (in C++ they’re classes).

There’s no inconsistency here, this is on purpose, and this has not been a problem in the past 6 years for Godot users, whether experienced or beginners.

int, float and bool are plain old data types (Edit: primitive types is more correct, POD types is a wider and potentially more confusing concept). Array and String are templates, which are not trivial. So it makes sense for templated types to be capitalized like other non trivial types (e.g. Object).

It GDScript really all that high-level? It basically just interfaces with Godot’s built-in C++ classes (a limited subset, at that), with python-like syntax and a few handy shortcuts like iterating over arrays more easily. And since GDScript does not exist outside of Godot—and never will—implementation details are important, since GDScript is its implementation, nothing more. There is nothing outside of the implementation that dictates what GDScript is supposed to be, or how it is supposed to work (the docs are only meant to describe what it is). This is a major difference between GDScript and “mainstream” languages.

GDScript has a lot of ties to the C++ of the engine it interacts with—those “implementation details” being some of them. If Godot used semicolons and braces instead of line breaks, colons and indents, would you feel the same way about this?

The real problem, though, is that any potential benefits of a change do not outweigh the obvious costs. True, there’s no reason GDScript has to use “int” instead of “Int”, but changing it will break every current Godot coder’s code and intuition with no real benefit. One reason it may have ended up this way is that it mirrors the names of those things in C++ (what the engine devs are seeing all day), where all the types added by the engine are PascalCase, and primitive types are all lowercase. Since the C++ functions GDScript interacts with all use the C++ built-in bool, int and float types, and Godot’s own Vector2, Variant, Array, etc. types, the current situation makes GDScript code nicely mirror the same code in C++. This isn’t very useful to those who only use GDScript, but is nice for anyone also using other languages with Godot. So I’ll have to disagree with your that “it would be nice” to change it.

In general, I’d say the engine’s syntax highlighting (and, relatedly, which things in GDScript are reserved words) is a little strange in 3.x (why are built-in functions like print and floor reserved?), but I just did some testing, and it seems master doesn’t really have globally reserved words (probably because of the parser rewrite). It does, however, still have weird highlighting if for some inexplicable reason you do var Node or var int (Node is highlighted green and int red when they should be white like other variable names).

I’d also suggest int, bool, and float should be capitalised to be consistent with the rest of the types.

I’ve already suggested. Also, it would solve the first problem automatically.

There’s no _in_consistency here

No, there is inconsistency with the following naming conventions:

var name: Name
func name(name: Name) -> Name
name is Name
name as Name

All types except these three have a capitalized name. Any exception is inconsistency. The only question is whether there are any advantages to having the exception.

this has not been a problem in the past 6 years for Godot users, whether experienced or beginners

This is only because this inconsistency affects only appearance, but not behavior. Just like the fact that these types are highlighted in a different color than the rest.

We can make a color for primitives a separate setting and let users decide if they want it to be the same as keywords, as classes, or have a unique color all together.

Sorry, but in my opinion this is useless. All types should be highlighted with the same color. Otherwise it will be too colorful: primitive types - in one color, built-in types - in another, classes - in a third, custom classes - in the fourth, 2D types - in the fifth, 3D types - in the sixth, etc.

I would ask you both: from the end user’s perspective do they care whether something is a primitive type or a class type?

Absolutely agree. What does knowing whether the type is primitive or not? What is the difference between a primitive type and a non-primitive type? I could understand if types passed by value were written with a small letter, and types passed by reference with a capital letter. Or built-in types with small, and classes with capital. The only reason these three types are written with small letters is tradition, habit, and blind copying of C/C ++.

it’s very common in most programming languages

Yes, you are right, it is, although it is absolutely pointless.

But in some languages (Kotlin, Haxe, Ada, etc) all types (even “primitive” ones) start with a capital letter, and this warms my perfectionist soul.

But since it does not affect behavior, this is not a change I would fight for. It’s just a little annoying that people think in such fictitious categories as “primitive” types. In comparison, the illogical and counter-intuitive behavior of the division operator creates much bigger problems, but people don’t want to notice them and react extremely negatively due to the strength of their habits.

GDScript is a high-level language because there are no pointers or other low-level memory manipulations. In terms of design and syntax, GDScript is a mixture of Python, JavaScript, and C++. But some things taken from C++ don’t fit well with the fact that GDScript is a language whose goal is to be simple for beginners. I disagree with the opinion that GDScript should look familiar to C++ developers.

This change is highly optional and insignificant, as most people don’t care. But even if it were accepted, the old code would be easy to fix automatically, unlike some of the other recent GDScript changes.

To summarize: in GDScript, primitive types are written in lowercase only because they are written this way in C++. There is no other reason.

@name-here These are not significant differences, just implementation details. In JavaScript, for example, you can do 1.2345.toFixed(2). GDScript is a high-level language, so the low-level details of C++ are not important here enough to emphasize these three types. Knowing about their primitiveness in C++ does nothing for a GDScript developer.

Once again, this is not a thing that I would fight for. I refer to it as “It would be nice.” I just wanted to show that “primitive” types are a strange tradition. But I face the objection that there are some real reasons to classify primitive types into a separate category. It surprises me.

Again, there’s two things in this issue:

• The original report that primitive types are wrongly colored. That’s a bug and I’m not even sure why it warrants discussion, they should be colored like any other type. PR welcome, that’s likely easy to fix.

• Renaming primitive types to Int, Bool, Float -> https://github.com/godotengine/godot-proposals I’m not interested in discussing this further here for the sake of perfectionism.

I second Akien about capitalization, but I want to remind everyone that the first part of this issue is about syntax highlight 🙂

So to address that… Of the top of my head I cannot remember if any other language in any other editor highlighted primitive types the same as keywords or not, but this can probably be arranged anyway on our end. We can make a color for primitives a separate setting and let users decide if they want it to be the same as keywords, as classes, or have a unique color all together.