User Defined Functions - When and when not to

[Ciaran Laval]

I'll start by saying I love functions, I use them probably way too often, I just prefer scripting that way as I find it easier to follow and tweak.

My rule of thumb (in SL) has generally been if you're using a line of code more than once, use a function, but is this correct? Functions I've just noticed as I read into it more, have overheads, I don't write heaps of code in a script, but is it better to avoid the overheads of functions or does using a few make very little difference?

[Rolig Loon]

I have generally followed that same rule, Ciaran.  I am not a coding professional, so I don't necessarily follow practices that are common among professionals.  That one does make sense to me, though.  The other basic principle I follow is readability.  Personally, I find it hard to follow the logic of a script if I have to wade through several instances of the same code snippet.  If I find myself using the same code to stop all animations or to close any open listen handles, I'd rather put those things into user defined functions and reduce the clutter in the main body of the script.  That makes the actual meat of the script stand out more clearly for me.

[Dora Gustafson]

---

Ciaran Laval wrote:

I'll start by saying I love functions, I use them probably way too often, I just prefer scripting that way as I find it easier to follow and tweak.

My rule of thumb (in SL) has generally been if you're using a line of code more than once, use a function,

but is this correct?

Functions I've just noticed as I read into it more, have overheads, I don't write heaps of code in a script, but is it better to avoid the overheads of functions or does using a few make very little difference?

---

You can't say if it is correct or not.

I once heard this said about a good program:

"A good computer program is a program that gets the job done."

If you can make it using subroutines and without it is yours, the programmer's choice what is preferable

[Ciaran Laval]

Reading the script more easily is definitely a reason I like using functions, that and being able to update the block of code in one place and have it work throughout the script is another.

[Ciaran Laval]

Oh certainly achieving the task is the primary aim of the script and how we get there is certainly an optional path.

[Void Singer]

depends on your goal... as a general practice, yeah if you're repeating the same code (or it's code that can be used in other projects) you should turn it into a function...

in LSL there are some stiff speed and size penalties to encapsulating code in functions though, especially with the lack of pass-by-reference. for instance, projectile scripts can often react faster with inlined code than they can with function code, even if there are several instances of the same code. the tradeoff is that it becomes a bit more of a pain to maintain (must be sure to update all instances), and can lead to subtle unexpected behaviors where two paths using the same code may trigger before the next step of either.

the performance gains may be worth it for some things, and may not for others... I tend to write the functionalized versions first, and then if I need the extra performance insert into it's call spots, and test for those subtle errors.

[Ela Talaj]

I'm yet to see a program, even if in assembler, written without user-defined functions. Main advantage is not readability but reusability and not necessarily in the same module (script). Yet, if maximum memory is a requirement as in storing a large number of entries or things like that, functions turn against you because the LSL lacks a concept of pointer, so it puts on the stack actual arguments, not references to them and the stack grows real fast and... collides with the heap For instance if you pass to a function a 5K list as an argument and then your function makes a system call (calls an LSL list method) your memory usage while executing this system call is 10K, not 5 as you now have 2 lists on the stack and you may not have these additional 5K.

[PeterCanessa Oh]

I've always advocated writing for readability unless there is a desperate need to squeeze every bit of performance/memory out of an application.  When a program needs amending or enhancing in a year or even 6 months the ultra-efficient optimised to the death version will look like gibberish* but you'll still be able to work with the 'clear' one.  So much of optimisation depends on the exact use, data, etc. that it's impossible to generalise further than 'yes, there are overheads for funcion-calls'.

(* I provide for this ahead of time by writing gibberish in the first place)

[Nelson Jenkins]

If you need speed and you're using only a few instances of 1-2 lines of redundant code, don't.

If you're using more than 3 lines in 3 places and a small speed decrease won't be a problem, do.

Case in point, if you're looking to reduce script memory usage (which I tend to be doing a lot these days) look around for redundant code, and if it's more than 3 lines in 3 places, you can probably sacrifice the speed for memory.

In languages other than LSL, it's pretty much common practice to use nothing but user defined functions anyway, particularly in object-oriented languages (i.e. most of them). But like others mentioned, user defined functions in LSL have an oddly large overhead in terms of memory and speed. Using one for only a few lines of redundant code sometimes seems to increase memory. Go figure!

For that matter, does anyone know if LSL is classified as OOP? I'm tempted to say yes due to the ability to run multiple scripts in the same object, but obviously LSL lacks... well, pretty much everything an object-oriented language has to offer.

[Void Singer]

short answer, essentially yes.

long answer, OOP is more practice than feature, but in theory Event Driven Programming tends towards Object Oriented... it can be violated in practice, but tends to work better if you don't. LSL's basic lacks (no pass by ref internally, limited privatization of functions) can lead to large violations in black box design, depending on the level you look at it.

[Ela Talaj]

OOD/OOP is mostly a state of mind A language is just a tool to deliver your state of mind to a machine. Having time and desire one can write object-oriented programs in assembler. Actually that is what happens when you write in C++ : the compiler would translate it into an assembler code. So there is your OOP in assembler

But the compiler has time (our minutes are its centuries or even millenia) and people don't. So high-level languages were created to quickly implement OOD. Basically they all do the same basic thing: allow the user to define user own data types. That's what all those fancy C++ clases are, just user-defined data types. In these data types user can combine data and methods operating on data and therefore define a real world object. Then a hierarchy of the data types is established (inheritance) and so on...

Yet C++ retains all features of C, including totally programmer-controlled memory management. (that is why no garbage collection). A true high-level object-oriented language takes care of most memory management on it's own, transparent to programmers. In this respect LSL is a true high level object-oriented language.