Debug function

I've started using this function as a slightly less tedious way of getting debug data out of a script than coding llOwnerSay calls. Is there a better way?

integer DEBUG = TRUE;

Debug (list data)
{
    if (DEBUG)
    {
        string result = "";
        integer length = llGetListLength (data);
        integer index = 0;
        while (index < length)
        {
            if (result != "") result += ", ";
            result += llList2String (data, index++);
            result += " = " + llList2String (data, index++);
        }
        llOwnerSay ("DEBUG: " + result);
    }
}

default
{
    state_entry()
    {
        float x = 9.999;
        integer y = -111;
        list z = ["abc", 123, ZERO_VECTOR, 456.789];
Debug (["x", x, "y", y, "z", llList2CSV (z)]);
    }
}

(Actually, I put it all on one line, to make it easier to comment out entirely.)

One thing to be aware of is that LSL is going to do everything by-value and nothing by-reference.. This line:

Debug (["x", x, "y", y, "z", llList2CSV (z)]);

Will *always* make a copy of the each of these things and call llList2CSV, even when you set DEBUG=FALSE.

Because of things like that, I tend to comment out the calls to my debugish methods instead of commenting-out or conditionally-not-doing stuff in the debug method itself.

Also, you'll probably get a 0.0001% performance boost by doing "if (!DEBUG) return;" at the top of that method. I tend to avoid having multiple exits in methods but LSL doesn't really encourage traditional 'good programming skillz.'

you can also eliminate the variable duplication by using an if with all your debugs

if (DEBUG) debug( stuff );

you can different levels of debug if that comparison is done against some bitflags giving only the info you need

if (DEBUG & L1) debug( stuff );
if (DEBUG & L2) debug( stuff );
etc... where DEBUG is a bitfield, and L1 and L2 would be bit masks like 1,2,4,etc

I advise stripping debug statments from final products though, unless there's some special reason to keep them

Yes, I do comment out both the debug method and the calls, and by commenting out the method the compiler helpfully reminds me of any calls I've forgetten about (though I've found that NOT indenting inline debug code helps me find it again more easily).

The TRUE/FALSE switch is handy for temporarily reducing the amount of spam I send myself when the debug output starts to overwhelm the actual progam output, and the point about passing parameters by value isn't lost on me - I've just been working on a script that ran out of memory because of the debug function. I like the bitflag idea and I'll certainly use that the next time I get myself involved in a horribly messy script (which'll be the next time I open a script editing window).

I don't think I'll worry too much about programming best practice in debug code

Thank you very much for your very useful comments and suggestions; they are much appreciated.

You can use DEBUG_CHANNEL:

default
{
state_entry()
{
llSay(DEBUG_CHANNEL, "Hello, Avatar!";
}

touch_start(integer total_number)
{
llSay(DEBUG_CHANNEL, "Touched.";
}
}
It makes the messages appear in the script warning/error window. But then you would lose the timestamp.

you're not the only one that does that.

Hah! You learn something new every day: I didn't realise that was open to the general public, and this sounds like a good way of preventing script output from being swamped by debug output. Thanks for that tip.

Yeah, I also don't indent it so it sticks out like a sore thumb. Comes from significant use of stuff like this:

#ifdef DEBUG
Blah();
#endif

Draco, how I miss preprocessor directives, macros, etc.

Oh you want those? Sure

LSL Preprocessor:
http://www.youtube.com/watch?v=J-2qmRn-Skk

Yus, in the standard viewer, though.