Best Practices in Rev development
Devin Asay
devin_asay at byu.edu
Wed Jun 20 11:04:42 EDT 2007
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
More information about the use-livecode
mailing list