Good ways to overcomplicate your code and slow down development

[Dar Scott]

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
dsc at swcp.com

Computer programming
**************************************