Scripters Scrapbook

[FlexibleLearning at aol.com]

In a message dated 28/08/2003 06:15:21 PM GMT Daylight Time, 
use-revolution-request at lists.runrev.com writes:

> Can you explain how the ScriptersScrapbook app is "different"? Also, any 
> other folks that have links to good examples of coding style and 
> methods, I would love to see them.

The main window is dynamically set on launch, that's all. It's designed to be 
a 'use whilst you work' tool, so is designed to be impervious to the 
authoring environment. Nothing more.

> I get the feeling that as powerful as RR is, there are plenty of ways to 
> abuse the language, like Perl.  The voices of experience would help 
> here. I.e., is it better to tuck little snippets of code away inside 
> lots of objects, or collect the code all at the main card level (as 
> ScriptersScrapbook seems to have done).

Anything used more than once should have its own code. Easier to maintain, 
track and manage. Shared handlers at stack level allow background, group and 
card-level modifications.

I collected the following tips and tricks over the years... Feel free to 
disagree, add or ignore.

-  Don't trash accepted interface expectations. Refer to the interface 
section of the Power Tips project bundled with SuperCard, the Mac HIG and Win HIG.

-  Read the Tech Notes supplied with SuperCard and the Concepts & Techniques 
stack supplied with MetaCard, and the extensive documentation with Revolution. 
Lots of useful tips.

-  Any operation used more than twice should have its own handler.

-  Balance length of handler with compiling time overhead and the 
shareability of smaller, more quickly compiled, utility handlers and functions.

-  Compact code is faster to run, but harder to unravel when you need to 
analyse it later. Use comments to explain "why" as well as "what", if not "how" as 
well.

-  Keep a list of all global variables, and put empty into them when you 
close the project for clean housekeeping.

-  Use a consistent naming convention: g_GlobalName, t_LocalName, 
a_ArrayName. Some folks also name built-in handlers and function with a lowercase initial 
letter and their own with an uppercase leet eg 'on mouseUp' but 'on 
ShowItems' so things can be more easily identified.

-  Collect all the data first, then operate on it rather than collect, 
operate, collect, operate.

-  Make handlers and functions as general as possible. You can then re-use 
them.

-  Make sure that anything passed to a function or handler can be handled, 
however unlikely, including empty perameters.

-  Keep a standard set of navigation handlers eg "goPrev". Adjustments are 
easier to implement.

-  The larger the number of items on a card, the slower it opens.

-  The larger the amount of styled text, the longer any operation on it takes 
to process.

-  Use draw objects rather than bitmaps... they load faster.

-  For a fast transition to a card with a large colour bitmap, put it in a 
separate window and open it invisible before showing the window.

-  Lock screen speeds up many operations, but frequent unlocking has a time 
overhead which increases with the number of items to be redrawn.

-  Setting lockMenus to true in SC speeds up menu operations by a factor of 
20.

-  Functions with brackets take longer than functions without brackets when 
you have the choice eg "topWindow()" is slower than "the topWindow" in MC.

-  Calculate once, and use a variable thereafter.

-  Add a zero to variable names in calculations to force them into binary 
format. Subsequent calculations are very much faster since they don't have to be 
interpreted as text.

-  Variables are much faster to access than other containers.

-  The more the variables, the slower the calculation; "add a to b" is faster 
than "put a+b into c" or "put a+b into b".

-  Prefix global variables eg g_VarName. They are then easily identified.

-  Put names in quotes. They are faster to compile since they are not checked 
as variables first, and you cannot unintentionally confuse them with a 
variable of the same spelling.

-  Beware of embedded repeat routines; they slow the execution exponentially.

-  The fewer the characters, the faster they compile; "num of flds" is 
quicker than "the number of background fields".

-  Preferences can be stored in a text file as well as fields.

-  Just because you can doesn't mean you should. Less is often more, 
especially with colour.

-  Try using modal windows rather than popup fields.

-  Back up regularly, and use version numbers. Three generations of work is 
better than two.

-  Differentiate between a comment line (note) and a commented line 
(disabled) eg

     ## This is a note...
     -- get myArray(n,t) ## now defunct  

... It helps debugging.

/H
_________________________________________________
Hugh Senior
The Flexible Learning Company
Consultant Programming & Software Solutions
Fax/Voice: +44 (0)1483.27 87 27
Email: mailto:h at flexibleLearning.com
Web: www.flexibleLearning.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20030828/fd0fa4de/attachment.html>