Best Practices in Rev development

Kay C Lan lan.kc.macmail at gmail.com
Wed Jun 20 22:59:37 EDT 2007


On 6/21/07, Robert J. Earp <bob.earp at ashford.ca> wrote:
>
>
> Richard, didn't you publish a paper on recommended coding standards?


Devin although I know your after 'Coding Best Practices' along the lines of
naming objects and variables with meaningful names, and using prefixes for
local/global/constants, then if you're compiling a list of tips for
debugging (assuming you don't use explicitVars)

Step through your script with the Variable Watcher open

1) Are there two variables that are almost identical
   lMyColourVariable and lMyColorVariable

2) Have I used gMyColour where I should have used lMyColour or pMyColour

Having eliminated these two common errors (for me anyway) it pretty well
only leaves an error in the algorithm logic - which of course is the fun
part of tweaking code to get the right algorithm.

Back to the topic of Coding Practices I'll throw this out there as I'm sure
there'll be plenty of opinion especially as we've seen a couple of comments
on well commented nested if-then-else statements and breaking large handlers
down into more manageable chunks.

For many many years I've been the creator of massively nested if-then-else
statements and have developed ways, as mentioned, to comment them to help in
later amendments of the code. I can't remember if HC has a Switch statement
but when I came to Rev I really wasn't aware of it until a Thread on this
List mentioned it. I know a few expressed how it 'didn't appear as logical'
as if-then-else, no matter how nested, and I must admit to begin with it did
take a conscious effort to get it to work, but much like Rev itself, once
the penny dropped, there was no looking back.

Since then, for any conditional statements, unless I know 110% that the
condition will NEVER be anything other than 2 options, Yes/No, Right/Wrong
then I ALWAYS use Switch. I have a template that looks like this:

on switch (pInput)
 case ("Yes")
  --do stuff here
 break
 case ("No")
  --do stuff here
 break
 default
  answer "You have ended up in a part of the program that was not intended"
  breakpoint
end switch

Even though this would appear to be better as if-then, further down the
track when I need to account for "Maybe", it's just a matter of inserting:

case ("Maybe")
  --do stuff here
break


What's even better is if I forget to put in the code for "Can You Repeat The
Question", then the program automatically tells me and stops right after the
point where I should add the next 'case' statement.

I tend to use your 3 line rule, in that if the statements in the case exceed
3 lines I'll write a separate handler. As such, the switch structures appear
very concise and very logical (to me) as to what they do and why.

I don't suggest a Best Practice for Switch statements, but if you can help
get the 'penny to drop' I think they can really help in keeping code
readable, manageable and best of all, very easily extensible.

Just my 53 shindarkles worth



More information about the use-livecode mailing list