On Sep 14, 2006, at 2:07 PM, Josh Mellicker wrote:
1. overhandlerize
This is true, especially in cases such as your example where the
custom command simply reiterates the underlying language semantics.
However, in my experience, apps are made overcomplicated by, uh,
"underhandlerizing" much more often. By breaking scripts up into
custom commands and functions that mean something in The Problem,
scripts are easier to write and later read, and are more reliable.
I don't think the number of lines contribute to scripts being
complicated very much. All script reading has to be done by mental
chunking anyway, so some scripts with lots of lines tend to be
simpler. Having said that, in my experience, scripts that tend to
break The Problem down into domain-oriented handlers tend to be much
smaller.
For scripts that need to run fast, Revolution unfortunately
discourages the use of handlers because of its high call overhead.
(There are some suggestions on bugzilla that might should decrease
this. the most popular is script-local commands and functions. You
will be glad to know that that will probably cut down on keystrokes.)
Breaking up The Problem into smaller chunks also allows for concept-
size testing and debugging, not just app testing and debugging. This
increases reliability.
2. Capitalize the first letter of all your Handlers, Variables, and
Stack, Card and Control names, etc. This will cost you hundreds of
keystrokes over a day's work and add to your carpal tunnel potential.
3. Declare your variables
Since typing is only a very small part of design and design review, I
do not agree. Anything that helps in reliability and in "grocking"
the script is a plus. My style is to put leading caps on objects,
avoid hungarian (unless requested) & long names and to only declare
handler variables where it makes script reading easier or to init
them, but others might "read" other code easier. When making a
handler, one paints an image where an idea jumps out.
Also, some folks don't use label/title properties and have automatic
card name field that beg for capitalization. If one doesn't
capitalize then one would need to use label/title properties to have
those show up right.
Also, a change in typing style will slow down typing (at least at
first), not speed it up.
Perhaps features like ScriptPaint make typing in variable
declarations easy. There is little extra cost in typing a script.
The key is how much it slows you down that you can't compile a
script and test immediately, instead you must first scroll to the
top and type "local tWhatever". This increases development time by
a significant factor.
This is caused by writing long handlers, not by variable declaration.
I do experiment when writing scripts to make sure that I understand
how Revolution or my environment really works, but I don't waste a
lot of time testing every time I come across a need for a variable.
I slap down a handler and test it.
I can't tell if you are being ironic or are serious. This isn't the
first time I have misunderstood a joke and took it seriously.
Perhaps folks design in different ways. I'm sure one typing with
whiff-and-puff would count keystrokes at a higher cost than I
(currently) do and I would when that day comes.
Dar
--
**************************************
Dar Scott
Dar Scott Consulting and Dar's Lab
8637 Horacio Place NE
Albuquerque, NM 87111
Lab, office, home: +1 505 299 9497
Fax: call above first
Skype: ask
http://www.swcp.com/dsc
[EMAIL PROTECTED]
Computer programming
**************************************
_______________________________________________
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
