The style guide and not equals operator

Godot Version

All.

Question

I’ve read the official style guide, but I have a question, as it leaves one thing ambiguous.

What about the != operator?

In the documentation, it recommends using not var instead of !var, but it has nothing to say about var != value as opposed to not var == value. Am I supposed to make my own rule here, or is there an official style guide for that too?

As I understand it, the guide is in place to help gdscript to be more human readable, and I have no idea which of the two options is more readable, if any.

Use !=. It’s a single operator, regardless of it having two characters. So it’s more economical than not var == value which uses two operators. It’s also more readable if you read it as “not equal”.

Hmm, is there a chance that can be explicated in the docs? Just so no one else has my question again?

IDK, it seems like a reasonable question to have, when reading the docs, especially if you’re coming from a language where !var is the norm.

The style guide is just suggestions. I find a lot of it to be counter-intuitive and ugly after my 40 years of programming. But that’s just my opinion. There is very little in the guide that is required (such as being whitespace-sensitive), so don’t feel like you have to constrain yourself to its suggestions.

As for the question at hand, != is far more common usage and is more readable in general.

In languages where !var is a norm, a != b is also a norm.

It’s not in the style guide because it’s self-evident.

Use Occam’s razor. Why use two operators if one operator can do it.

@normalized and I are going to agree. :slight_smile:

Prefer human readability.

if not my_var == value:

if my_var != value:

The latter is much clearer.

However, also avoid negatives when you can. For example, when checking for null, prefer:

if my_var:

over

if not my_var == null:

So going back to your original question, I would use better variable naming to avoid using != at all in any form. Personally, I rarely do comparisons like that in reality.

Instead you see things like this:

func _physics_process(delta: float) -> void:
	if not is_on_floor():
		velocity += get_gravity() * delta

(The alternative would be if is_on_floor() != true or if is_on_floor() == false.)

Or this:

func _on_body_entered(body: Node2D) -> void:
	if not body is CharacterBody2D:
		return

(There’s actually no way to do this test with !=.)

If you feel strongly about it, contribute to the documentation. The team will either approve it or tell you why it isn’t spelled out. The documentation is maintained by us, the community.

Personally, I think you are focusing on something that doesn’t matter because you haven’t used Godot enough to know that.

To this point, what I tell people on here is if you use the style guide, it’s easier for other people (and future you) to read your code. If, like @soapspangledgames you have another, long-established, style and you’re the only one reading your code it doesn’t matter what you use. But it also makes it easier for you to read other people’s code IMO.

If you follow the style guide then when you come here to ask for help, it’s a lot easier to get an answer. When someone uses PascalCase for variable names and snake_case for constants, it makes it much harder to read their code.

GDScript style guide is actually very reasonable. I don’t have any objections there, except I use 3 lines of space between methods instead of suggested 2.

Agreed.

Interesting. How come? Do you use 2 spaces somewhere else?

The style guide has changed since I started. @onready and var got switched in the order, and spaces between @export, var and @onready went from 2 lines to 1 line. I just followed along.

Thinking about it, I’d say this is not even a matter of style. Doing not a == b is bad coding, regardless of style.

2 lines don’t make enough “contrast” in respect to single line spacing between blocks inside methods. Since I don’t use any other separators between methods, I like to have a bit more visual separation there.

Agreed.

Great learning opportunity altogether. I marked @dragonforge-dev’s answer as solution, as it elaborates a lot over the issue I was having.

Thank all for the inputs :3