this post was submitted on 30 Sep 2023
24 points (96.2% liked)

Godot

5884 readers
1 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 1 year ago
MODERATORS
 

I’m just curious about which is the most efficient way of doing this kind of node enumiration:

for i in something():
    o=[var1,var2,var3,varN][i]
    o.new()
    o.do_something_based_on_number_of_loops()
    add_child(o)

or

for i in something():
    match i:
        0:
            o=var1
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)
        1:
            o=var2
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)
        2:
            o=var3
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)
        N-1:
            o=varN
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)

or

var items = [var1,var2,var3,varN]
for i in something():
    o=items[i]
    o.new()
    o.do_something_based_on_number_of_loops()
    add_child(o)

Or is there a more efficient way of doing it?

Edit: Sorry if that wasn't clear. Is it better to constantly get something from an "unstored list", store the list in a variable, or not use a list and use a match statement instead? Do they have any advantages/disadvantages that make them better in certain situations?

you are viewing a single comment's thread
view the rest of the comments
[–] tabular@lemmy.world 0 points 1 year ago* (last edited 1 year ago) (2 children)

If speed is actually important then I would consider ~~writing it in another language~~ looking for someone else's implementation (personally). I try to focus on readability and doing the simplest implementation. I've been trying to use better function/variable names to explain what is happening at a glance instead of reading the whole thing. Have you considered using map for array iteration? I am hoping even if people don't know how this works the intended result is even more readable than an equivalent for loop:

func _show_only_first_layer_dots():
	var set_dots_visibility = func(layer): layer.get_node("Dots").visible = (layer == $Layers.get_child(0))
	$Layers.get_children().map(set_dots_visibility)
[–] Tranus@programming.dev 5 points 1 year ago (1 children)

I find that much harder to read than a for loop. You are making a helper function to only use it once, which is kind of confusing when it is totally unnecessary. Also, distinguishing between two groups only inside the setter line is weird. Applying the modification to one group, then the other, is more obvious. Considering the alternative isn't really longer, and only using basic loop syntax, I would just use the loop. If you really want to add the "set dots visibility" explanation into it, just use a comment, that's what they're for.

I literally just now misunderstood your code and had to change my comment to correct for it.

[–] tabular@lemmy.world 0 points 1 year ago* (last edited 1 year ago)

You looked at how it works and made comments about that (which I am thankful for and will enjoy replying to below). Can I first bring your attention to what is does instead of how it does it. Do you think that the names of the method function and helper function made it's intended result clear? Could the use of map be so unexpected as to be a distraction?

I shouldn't have included the node.visible = (expression) in the example, that was needlessly complex. It's just what was in front of me (I do however find it appealing because it reduces the number of lines but that is another discussion).

While for loops are a popular method taught to every programmer early on then a for loop is easier to understand step by step. I do find occasions where a for loop just looks better but I keep finding that I better understand what my code is actually doing when I try to write a loop using functional programming methods.

[–] Rodeo@lemmy.ca 2 points 1 year ago* (last edited 1 year ago) (1 children)
func _show_only_first_layer_dots():
    for c in $Layers.get_children():
        c.get_node("Dots").visible = false
    $Layers.get_child(0).get_node("Dots").visible = true

Mines 10x more readable ~~and I saved a line of code.~~

Simplicity is king.

[–] tabular@lemmy.world 0 points 1 year ago* (last edited 1 year ago) (1 children)

If you're working on the function then yes; everyone learns for loops fairly early on.

If you just need to know what it is intended to do then I would argue you didn't need to read anymore than the function name. If you do look further then I'd argue just the name of the helper function was easier to read than the whole for loop.

[–] Rodeo@lemmy.ca 1 points 1 year ago (2 children)

It's a poor name choice then, because it actually says less about what it's doing than the main function does.

Besides, what is the point of "looking further" just to stop at another function name? Wouldn't looking further imply the need to review the implementation?

[–] tabular@lemmy.world 1 points 1 year ago

Seeing another function divides the code into another subsection. In the example it's the only one there but if more was added then you could choose where to focus your attention on the implementation.

[–] tabular@lemmy.world 1 points 1 year ago

In practice it turns out the method to make just the first element visible was redundant anyway. It would be made visible during the setup function that all elements call.