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 | [email protected]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
