this post was submitted on 04 Jun 2026
28 points (96.7% liked)

Godot

7652 readers
10 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

!roguelikedev@programming.dev

Credits

founded 3 years ago
MODERATORS
 

UPDATE: The consensus seems to be overwhelmingly in favour of the match variant. And not to worry, I have replaced the magic numbers with an enum. Will try to remember to merge the branch tomorrow

Does an if-statement block or a switch statement fit better here? For context (and advertisement), this is part of my all-purpose utility plugin ( Codeberg link)

The code:

		# Method 1 (Yandere Dev Technique)  
		if self.throw_errors and status==MpupTest.TESTSTATUS.ERROR:  
			push_error(result)  
		if self.throw_warnings and status==MpupTest.TESTSTATUS.WARNING:  
			push_warning(result)  
		
		# Method 2 (Pirate Software Technique)  
		match status:  
			MpupTest.TESTSTATUS.ERROR:  
				if self.throw_errors:  
					push_error(result)  
			MpupTest.TESTSTATUS.WARNING:  
				if self.throw_warnings:  
					push_warning(result)  
top 15 comments
sorted by: hot top controversial new old
[–] SteleTrovilo@beehaw.org 12 points 2 days ago

The match statement is cleaner.

With the sequential if statements, it might seem on a casual read that both if statements could pass - you'd catch both warnings and errors. Only by looking at the conditions do you realize that only up-to-1 of them will run.

With the match statement, it's very immediately obvious that only one of the commands will run.

[–] refalo@programming.dev 10 points 2 days ago* (last edited 2 days ago) (1 children)

If status is modified in another thread you could have a race condition with method 1 because you're checking it twice. The two methods are not exactly the same code due to that. If you want to mimic the case statement of method 2, change the second if in method 1 to an elif.

Not to worry, the variable is local and the function is single-threaded.

The elif is a good idea, though - although I'll likely go with a switch statement in the end.

[–] lbfgs@programming.dev 6 points 2 days ago (1 children)

Not sure about how to do this with Godot, but a common pattern for this in other languages is creating something like a 32 bit value where the lower bits are the enum and the upper bits are the status code (assuming they are <=16bit each) and then doing a switch on the resulting packed value.

[–] sp3ctr4l@lemmy.dbzer0.com 3 points 2 days ago

Both these devs are far too full of themselves to think of using an enum table or anything clever with datatypes themselves.

Because that would mean the way they've been doing things was potentially grossly inefficient at runtime... and they've been doing that for years...

But a narcissist never makes a mistake, so instead, here's a bunch of reasons why actually writing optimized code is stupid, first among them being 'well it didn't occur to me, therefore doing it this way would reduce code readability for this code base that only I and no else needs to read'.

I am guessing the concept of a sentinel value or an overloadable function would make their minds implode.

But anyway, 'switch' is 'match' in gdscript:

https://docs.godotengine.org/en/latest/tutorials/scripting/gdscript/gdscript_basics.html#match

	<pattern(s)>:
		<block>
	<pattern(s)> when <pattern guard>:
		<block>
	<...>```
[–] copygirl@lemmy.blahaj.zone 5 points 2 days ago* (last edited 2 days ago) (1 children)

Are 1 and 2 magic values in this case?
You could use consts or even use an enum to further improve readability:

const STATUS_ERROR   := 1
const STATUS_WARNING := 2
# or alternatively:
enum Status { FINE, ERROR, WARNING }

In the latter case, you'd change status to be the new enum type Status.

edit: Wait, nevermind. I think you're already using enums in the actual code (not screenshot).

[–] MousePotatoDoesStuff@piefed.social 5 points 2 days ago* (last edited 2 days ago)

Oh yeah, I forgot to update the screenshot, yes. Thanks for reassuring me that it was good decision to use an enum!

[–] protogen420@lemmy.blahaj.zone 5 points 2 days ago

i am rust dev so I pretty much just use match all the time

[–] darthelmet@lemmy.world 1 points 2 days ago (1 children)

Naively: Isn’t the second one slightly better because the first one will always check both variables twice but the second one only checks one of them once then the other variable once when inside?

You're right, it is slightly better. Not really a concern here since this code runs only once per run for each unit test (and only for debugging, it's not meant to be in the game release) so it shouldn't be a performance issue, but still.

[–] Ledivin@lemmy.world 3 points 2 days ago

I'd personally lean towards the switch pattern

[–] tabular@lemmy.world 1 points 2 days ago (1 children)

I would be tempted to rename "result" to something more descriptive.

[–] waldfee@feddit.org 1 points 2 days ago* (last edited 2 days ago) (1 children)

Imo result is more descriptive than even Java-esque variable names, because it tells you that this is the variable that will actually be returned, rather than just some intermediate representation

[–] tabular@lemmy.world 1 points 1 day ago (1 children)

The function name ought to describe what is being returned?

[–] waldfee@feddit.org 2 points 1 day ago* (last edited 1 day ago)

Yea, basically. Like, the users shouldn't have to look at your implementation to find that out what it will return. My example here would be Square.area(). Maybe they would have to look at the method's docs though to find out what unit the result is in