Best Practices in Rev development
alex at tweedly.net
Mon Jun 25 18:22:21 CDT 2007
J. Landman Gay wrote:
> Richard Gaskin wrote:
>> So given the freedom of not using explicitVars while fleshing out
>> algorithms, is it really a valuable thing and I'm just lazy?
Sorry I'm late to the party, but Ive been busy - and I would like to
speak up in support of explicitVars. In fact, I have two answers to give
- a quick 'blow-by-blow' response to these points, and then (in a
separate email) a serious (even if not yet fully thought through)
proposal for an improvement (called, for the moment, "implicitVars")
> For the record, I don't like explicitVars because:
> 1. The main strength of xtalk is that you do not have to declare or
> type variables. Sticking them up there at the top of every handler
> removes one of the main advantages of using Rev in the first place.
"main advantages" - surely not. Even if it is an advantage, this can't
be a "main" one, can it ?
> 2. You can't comment out a long handler using a single set of hyphens
> before the "on" statement. (I often write multiple versions of
> handlers and switch between them.) As soon as you do that, all those
> "local" declarations become script locals and everything goes haywire.
> You have to comment out all of the declarations. If they aren't all at
> the top, you have to comment out the whole handler. That's more work
> than it needs to be if you're going back and forth between a few
> copies to see which one works best.
That means not only do you not use explicitVars and declare all
variables - you don't declare any (local) variables. That seems to me a
non-robust practice - especially if you share code written by others, or
use their code; having just a few variables that were for some reason
declared become script-local could lead to very hard-to-find bugs.
Also, as keen user of colorization in scripts, I like to have the color
properly represent the status of the lines of script and this habit of
disabling a handler without having it properly become a comment disturbs
the value of colorization.
Far better, surely, to have support for enabling/disabling a handler
either in the language or in the script editor.
> 3. It looks busy and it makes scripts denser and more complicated than
> necessary. I've seen handlers where the declarations can take up
> almost as much room as the code. It's hard to read other people's
> scripts if they use explicitVars because you have to skip over so much
> junk to get to the real business. In large projects it can add
> significantly to the file size on disk.
file size on disk ? what decade is this :-) ?
It's uncommon (I contend) for real scripts to have the number of lines
of declaration be as much as 10% of the number of lines in a handler -
insignificant compared to Rev's habit of storing both raw and formatted
version of the script.
But I do agree it can make the script denser, longer and harder to read
- see my proposal for implicitVars.
> 4. If you change a variable name, you have to go back and change the
> declaration. It's more work to maintain, for something that isn't even
> required by the engine. (I have wondered if people sometimes do it to
> make their code look more like "real" programming to other people.)
Who cares about the engine - I care about the readability of the script,
and the ease of early detection of bugs. If you change the name of a
variable that should (??) imply change of intent or purpose for that
variable - which means to me that it isn't a bad thing to
examine/consider each usage of the variable - so explicitVars is pretty
helpful in finding them.
> 5. And finally, what's wrong with being lazy? :) The smart programmer
> finds the easiest way to do things. That's what Rev is all about.
Nothing, intrinsically. But the smart programmer should find the best
way, not the easiest :-)
> None of these things is outweighed for me by the fact that
> explicitVars might catch a few typos. The engine catches most of those
> anyway and throws an error.
I don't find that the engine finds most of them - but I may make fzr
mpre tipos then must poeplr di.
Alex Tweedly mailto:alex at tweedly.net www.tweedly.net
More information about the use-livecode