Best Practices in Rev development

[Devin Asay]

On Jun 19, 2007, at 11:17 PM, Shari wrote:

>> The list is at <http://revolution.byu.edu/design/bestpractices.html>
>>
>> I'm interested in anyone's thoughts about them.
>>
>> Are they helpful?
>> Could some of them inadvertently cause problems down the road?
>> Have I left something important out?
>
> on Thoughts
>
> Name all objects:  Absolutely!  Even using an ID can come back and  
> bite you later.  There are situations where even that can change.  
> For example, you inadvertently copy and object without realizing  
> it. You discover this later, and delete one of the two.  If you  
> delete the one whose ID you used in a script, OOPS!  I know there  
> are other cases where an ID would change.

Excellent point. And this happens quite a bit with beginning  
students. How easy is it to inadvertently alt/option-drag an object?  
Or Command/Control-C then Command/Control-V,V? (Oops! didn't realize  
I hit paste twice!)

Another naming gotcha: Have you ever gotten an "object doesn't exist"  
error, and you check the name and it looks exactly right and you  
spend a long time trying to figure out why your handler can't see it?  
This happened to me years ago in HyperCard, and I spent many hair- 
pulling-out minutes trying to figure it out. I finally discovered  
that I had put a space at the end of the button name in the button  
inspector dialog. I deleted it and, presto! Button now exists!  
Nowadays that's one of the first things I check in situations like this.
>
> Comment your scripts:  Agree again.  Sometimes naming the handler  
> to match isn't enough, especially with a long script.  One thing I  
> do with very long scripts with many if's and repeat loops nested,  
> is to comment the beginning and ending of an IF or REPEAT, in order  
> to match them up.  I've got scripts where it's nearly impossible to  
> figure out which END goes with which beginning.  And if you're  
> trying to troubleshoot, having things well labeled can be a lifesaver.

Agreed. I do something like this, too. I also comment 'else' clauses  
with the condition that matches it, or a comment explaining what  
conditions should trigger that clause, like this:

if fld "firstname" contains "Tom" then
    # really long list of instructions
    # and somewhere, scrolled out of sight is the...
else # firstname doesn't contain "Tom"
    # do other stuff and never forget
    # who this else belongs to
end if
>
> Cross platform issues:  There are many more issues than text and  
> colors.  Option buttons appear so much differently that I had to  
> force one program to use a particular look and feel on every  
> platform.  There were no button style choices that looked and  
> behaved as desired on all platforms.  Preference locations and  
> permissions issues are vastly different.  My Mac users almost never  
> bump into permissions issues, but my Windows users are constantly  
> encountering this, so I've had to change how I save anything on  
> Windows.  So check your stack on several computers to make sure it  
> saves data properly to whatever text files, preference files, or  
> stacks you have with changing data.  Creating desktop shortcuts is  
> also handled differently depending on the platform.  Too many  
> differences to recall at 1 a.m. :-)
>
> Another cross platform issue:  Consider the screen size, and how  
> the menus will vary from platform to platform in relation to  
> affecting your available screen real estate.  So choose a stack  
> size accordingly.  Remember that Macs will have not only a Mac  
> menubar, but the dock as well, affecting your available territory.   
> If you want your stack to completely fill the screen, don't use a  
> menubar, use buttons in the stack window.
>
> BIGGEST cross platform issue:  Don't hard code your file paths for  
> preference file locations!  If you do, they might work today, but  
> tomorrow they will break, guaranteed.  How many folks ever  
> hardcoded the path to C/Program Files or something similar?  With  
> all the Windows permissions issues, as well as issues for other  
> countries systems being slightly different, always use Rev's built  
> in specialFolderPath().

Thanks for these ideas. I spend a day on building standalones and  
cross-platform issues, so I will include some of these considerations.

Regards,

Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University