nested IF statements and State issues

I have a vehicle program with some decision trees that require multiple nested IF statements. There seems to be a limit of 10 when suddenly the program fails to compile with a really random error message on a line that did not fail before. Anyone out there to confirm if there is sucha limit?

Does anyone know the time/script peformance penalty for IF statements?

The script is fairly elaborate and only has the default state, with numerous Ifs to determine the attitude and location of the vehicle and when it is approaching a sim boundary etc. When is it better to just create states rather than IF statements?

Anyclues would be helpful.

Use lslint for better compile error messages.

The compiler has a rather limited stack and the error codes are caused by that.

I tend to put ifs in functions so rather than else, I exit. Not programming 101, but it seems to allow more complex if structures.

There is, in fact, a limitation of the LSL compiler regarding nested ifs, and it presents itself in exactly the way you described.

Another way is to use jump statements to get out of a list of if's but be aware that a label can only be jumped to from one jump statement. That is, you can't have multiple jump statements aimed at the same label.

I realize that sounds absurd but it is true.

If the function is that complex, it should probably be broken into smaller functions anyhow, regardless of whether LSL's compiler chokes on it or not. If I found if statements nested to ten levels deep in a function at work, I'd hunt down the responsible coder and beat him to death with a wet spaghetti noodle.

That's all well and good, except LSL doesn't have any niceties like switch/case statements, hash tables, function pointers, or anything else that would help one avoid a long string of ifs.

Functions allow you to avoid the nest depth limit.

For example:

main()
{
    if (a) {
        if (b) {
            ab;
        } else {
            anb;
        }
    } else {
        if (b) {
            nab;
        } else {
            nanb;
        }
    }
}

has a nest level of 2. Using functions:

f_a()
{
    if (b) {
        ab;
    } else {
        anb;
    }
}

f_na()
{
    if (b) {
        nab;
    } else {
        nanb'
    }
}

main()
{
    if (a) {
        f_a();
    } else {
        f_na();
    }
}

we get a static nesting level of 1, with a dynamic nesting level of 2.

Used intelligently, it can increase code readability as well.

In addition, early returns are very helpful for reducing static nest level and increasing code readability and maintainability. For example, instead of the following:

{
    if (error1) {
        handle_error1;
    } else {
        blah blah
        if (error2) {
            handle_error2;
        } else {
            blah blah2
            if (error3) {
                handle_error33;
            } else {
                do_it;
            }
        }
    }
}

use this:

{
    if (error1) {
        handle_error1;
        return;
    }
    blah blah;
    if (error2) {
        handle_error2;
        return;
    }
    blah blah2;
    if (error3) {
        handle_error3;
        return;
    }
    do_it;
}

Which is easier for YOU to read?

<rant>
I've had ivory tower structured-code geeks recommend against this, but it's always based on comparisons between unstructured code with returns willy-nilly versus structured where returns are only allowed at the bottom. I find the above form to be much more readable and maintainable, after decades of experience training team members to adopt it and paying attention to their feedback.
</rant>

{ 
    if (message == "help")    {handle_help ();      return;} 
    if (message == "jump")   {handle_jump ();    return;} 
    if (message == "walk")    {handle_walk ();     return;} 
    if (message == "crawl")   {handle_crawl ();    return;} 
    if (message == "dawdle") {handle_dawdle (); return;} 
} 

This would not pass programming 101, but I find this quite readable.