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