Newbie... Strict Compilation mode

[J. Landman Gay]

Jim Bufalini wrote:

> - It allows you to distinguish globals from script locals and constants both
> at the script level and handler level.

You can do that without declaring them explicitly too.

> - It allows you to declare globals from inside a handler (which creates a
> "semi" global that is only available to other handlers that also declare the
> same global). 

You can also do this without turning on explictVars. It is, in fact, a 
direct feature port from HyperCard circa 1989. I also routinely declare 
script constants, locals and globals at the top of scripts, because that 
is the only way to get them. But that isn't the same as requiring a mess 
of declarations inside every single handler.

> - It makes your code much more readable, not only to others, but to
> yourself, when you are troubleshooting a problem weeks or months or years
> later.

Disagree. It makes your code messy, adds tons of extra lines that you 
have to skip over to get to the real code, isn't necessary, and clutters 
up the script with top junk. It isn't clean and I find it much less 
readable. I would go so far as to say it is inelegant. It is the 
opposite of writing the smallest, most concise code possible. To 
understand my scripts later, I add comments and choose self-commenting 
variable names. Declarations aren't as informative as good commenting.

> What, if any, is the advantage of NOT declaring variables? ;-)

Here's the response I gave 2 years ago when this came up:

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.

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.

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.

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.)

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.

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.

Back to today's response:

The debugger pinpoints the exact source of the misspelling if it 
happens; how hard is that? I'm a pretty good typist though, so I don't 
get caught out too often. I suppose if you are really as bad a typist as 
your theoretical example, then yes, you'd want some help. ;)

I once took over a project from someone who used explicit variables. I 
stripped out all the declarations so I could read the scripts 
comfortably. The stack size was cut in half (!). No lie. There were all 
kinds of handlers in there with something like 8 lines of declarations 
and three lines of actual script. Waste of time and space.

My fourteen cents.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com