Best Practices in Rev development

[Alex Tweedly]

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