infinite looping

Page: 1 2 3
Jul 11 2013, 8:33 am
In response to Jittai
Jittai wrote:
But I do use goto in specific cases, what's so bad about goto? :I

SHUN! SHUN! BURN THE NON BELIEVER.

RABBUU RABBUUUU RABUUUUUUU
Jul 11 2013, 8:36 am
In response to Jittai
Jittai wrote:
But I do use goto in specific cases, what's so bad about goto? :I
The fact that you don't ever need it? lol I love you, Jittai.
Jul 11 2013, 8:44 am
In response to Jittai
Jittai wrote:
> > if(ismob(a))
> >    var/mob/m = a
> >    m.MOB_ONLY_VARIABLE = dowhateverhere
> >    m.MOB_ONLY_PROC()
> >

The above is much safer and better design than...
> > if(ismob(a))
> >    a:MOB_ONLY_VARIABLE = dowhateverhere
> >    a:MOB_ONLY_PROC()
> >

How are these two different? ismob() ensures its a mob, not using : just seems like something you should avoid using if you're just starting out. And even if it does fuck up once, it's probably the most easiest thing to fix...

client
    verb
        test()
            var/T = src
            T:some = 0

mob
    other
        var
            some


It's basically a catching errors problem. : will only catch the fact you've referenced a variable/procedure that doesn't exist if the is literally no such thing in your entire code tree, all of it.

What this means is, you go rename a fairly generic counting variable like "action" to be called "next_action" on one part of your hierarchy, and coincidentally have another variable called "action" elsewhere, unrelated, your code will carry on compiling, even though the variable : is referencing doesn't exist.

Your code runs, then boom, runtime exception, and your game has itself a nice bug, you've embarrassed yourself with your playerbase etc.

But I do use goto in specific cases, what's so bad about goto? :I

The issue with goto is basically readability. It's flexibility is it's problem. You can jump from any part of that procedure to any other part, and the fact you've done so isn't usually that intuitive to people reading your code (even people like me won't spot it very quickly sometimes). Consequently, it's easier to make a change somewhere without appreciating you're actually inside a looping construct. Duplication, performance degradation, and some general WTF ensues. You tend to get a "mental pipeline stall" also. You hit the goto, then suddenly have to back out a bit and scan the procedure for where that label is. It's not guaranteed to be above/below, could even be buried in some nested statements. Throws a bit of a spanner in your train of thought.
Jul 11 2013, 9:04 am
I only use 'goto' in floodfill-like cases, which has the goto literally 4-5 lines above and I need something that can pull and list together and store it while it performs the same search on the last entered entries. If it causes performance issues I'll look for an alternative- but in the two systems I use this technique the performance is not at all an issue and deals with alot of objects.
Jul 11 2013, 9:06 am
It's usually more "Whoops, I didn't mean to do that" issues. Most of these practices surround making your life easier from a debugging and refactoring point of view.
Jul 11 2013, 9:31 am
In response to Jittai
Jittai wrote:
But I do use goto in specific cases, what's so bad about goto? :I

Pretty much like everyone else has said, it just makes your code less readable. But I mean, for all intensive purposes, if you prefer goto over a for() or while() loop, be my guest. However, it also probably means you should be sectioned by mental health services, but I digress.

I like more standard loops because they create a new block of code, something that obviously stands out from the rest as, "Yep, this is something new." Using preprocessor commands in the middle of a function looks better than a goto tag. And that's saying something.
Jul 11 2013, 9:44 am
I only use it in specific cases, in fact a very-specific case, which I'll look at it later but I recall while() not working out the way I needed it to. But, claiming to prefer goto over while() is an exaggeration.
Page: 1 2 3