Scripters Scrapbook

Thu Aug 28 14:27:00 EDT 2003

Thanks very kindly for taking the time to answer my question and make 
such a long list of style suggestions.  It will probably take me a while 
to absorb the full meaning of these, but coming from someone 
experienced, I intend to give them a great deal of consideration.

You mention SC and MC, and as a Unix and Windows person, I am not that 
familiar with these.  Are there links still available to these?

-Steve

FlexibleLearning at aol.com wrote:

> 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
> 