mwieder at ahsoftware.net
Sun Nov 6 14:11:04 CST 2005
I know others will chime in here, too, but since I have the chance to
draw first blood, here goes...
Sunday, November 6, 2005, 9:59:22 AM, you wrote:
> * Functions: From what I read, a function can be called by any other
> handler in a given script. Is it therefore best to define functions at
> the beginning of a script, before any event handlers? If I want to open
> a function up to the whole application, should I define it in its own stack?
There's no performance hit to the order of things. They get compiled
anyway. Richard's got a great writeup of the message-passing
hierarchy, and that should help as a guideline to where to put
functions. I try to place general-purpose functions either in the
mainStack or in a separate library stack and use the "start using"
> * Variables: I understand that vars are defined when they're initialised
> (except globals, which need to be declared). This upsets my sense of
> order somewhat, but I can see the advantages. That said, is it best to
> declare variables anyway? Is there any performance impact if I do or
> don't? Is it best practise to use the explicitVariables property?
I *always* declare my variables and have "script checking by default"
enabled (explicitVariables). There's no performance hit for this
except for having to do the extra typing of declaring the variables.
The upside of this is early bug detection, as the compiler will find
typos for you when you press "Apply", before they become a problem in
the runtime code. Well worth the pain, IMO, of having to type two
> (1) Local variable - accessible only within the handler that contains it
> (2) Script local variable - accessible to all handlers within the script
All good, but note that your syntax isn't going to be accepted. It's
put 5 into intValue
multiply intValue by 5
put intValue * 5 into intValue
> (3) Global variable - accessible to all handlers in the application
Avoid the use of globals whenever possible <ducking>. This one's
controversial as well, but I always try to pass parameters or use
custom properties instead if I can. There will always be some places
when you can't avoid it, but globals cause all kinds of trouble. Note
that the commonly-accepted notation for globals is to prefix them with
a "g", i.e., global gIntValue
My usual way out of using globals is to provide "get" and "set"
functions for variables that would otherwise be global:
-- in the stack script
on SetIntValue pNewValue
put pNewValue into intValue
> any background in HyperCard, so I want to make sure that I start out
> with good scripting habits for use in the Rev world.
...what Dom said here about unlearning HC habits...
mwieder at ahsoftware.net
More information about the use-livecode