Best Practices in Rev development
Scott Kane
scott at cdroo.com
Wed Jun 20 22:26:59 EDT 2007
From: "Ken Ray" <kray at sonsothunder.com>
> Actually, I have a stack I made that allows you to develop without local
> declarations and then after the fact run this utility and it will
> add the declarations for you. :-)
Sounds very interesting. :-)
You know - for me this was one of the big issues when I came to Rev.
Previoulsy I'd worked in various flavours of Pascal, C++ and if my arm was
twisted hard enough - BASIC. I was content with declaring variables and
with being required to do so. Further I had to define the nature of those
variables as int's, strings, char's, pointers and so on. One becomes so
used to this paradigm that Rev seems - at first - total variable anarchy.
It's one of several "culture shocks" one experiences when working with Rev
after working with languages afore mentioned. Changing the nature of a
variable in a loop? Why would I ever want to do this? Why would I ever
want to put a square into a round hole? I can see why the flexibility is
desired by mature Rev coders - at least I can see it now - but inititally it
seemed totally nuts to me. <g> So I developed my own method of commenting
the start of each handler where I "declare" my variables inside the comment
block so that I know what they are doing - twelve months or twelve years
down the track. I also "declare" them so that the nature of those variables
is clear at a glance. Inititally I'd just use i as an integer or s as a
string etc. Over time I evolved in this in my Rev code so that imyLines
would be a possible variable name or sMyText etc and so on. Rev makes it
easy to do things that might become sloppy and hard to maintain by providing
the flexibility to make it possible. IMHO rules are a good thing and self
imposed - clear to read rules - imposed by ourselves in our own code are
essential.
IMHO this is one area Rev needs to address on their website because it is
not something one can get a handle on by perusing the docs.
Scott Kane
More information about the use-livecode
mailing list