Good ways to overcomplicate your code and slow down development

Josh Mellicker josh at dvcreators.net
Thu Sep 14 16:07:20 EDT 2006


One of the great things about Revolution is the speed of development,  
and how the language can lend itself to minimalist, simple, elegant  
script structures and code. One line to do the work of many.

However, even the best fall prey to bad habits, some perhaps from  
other dev environments, that slow us down and rob us of precious  
time, as well as making apps overcomplicated, and needlessly  
difficult to debug and expand.

Here are a few common ways I've learned to overcomplicate scripts and  
slow down software development.


1. overhandlerize

	instead of simply:
	
	set the uFlag of me to true
	
	
	make everything a handler:
	
	setUFlag true
	
	
	ON setUFlag pFlagValue
	  set the uFlag of me to pFlagValue
	END setUFlag
	
	Cons:

	 - it gives you 4 lines of script from one, making your script  
longer, and more time consuming to scroll and look through
	
          - by breaking it out into a separate handler there is one  
more "moving part"- one more thing to go wrong
	
	 - it means if something goes wrong, you now debug 4 lines of code  
instead of one, maybe in two different scripts requiring you to trace  
through multiple pages,s lowing down debugging
	
	 - it makes your handler list bigger, making it harder and slower to  
find a handler

	 - now, you need to remember the handler name, but you still  
probably need remember the custom prop name too, giving your brain  
more things to keep track of and requiring more caffeine
	
	And then, instead of just saying:
	
	 IF the uFlag of me THEN
	
	 you continue in your overhandlizing:
	
	 IF getUFlagValue() THEN
	
	 FUNCTION getUFlagValue
	   return the uFlag of me
	 END getUFlagValue
	
	
Lame argument in favor of overhandlerizing: "Ummmm... now you can  
change your custom prop name in just one place."
	
Whaaaa???? First of all, why change a custom prop name? And why is  
that any more likely than you wanting to change your handler name,  
meaning you'll have to change it in THREE TIMES as many places??  
(call, begin and end hander)
	
Nooop! Sorry, but thanks for playing.


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
Yes, yes, I know, this might be a religion to some, but I have  
analyzed the situation carefully and I believe in most cases it's an  
example of one step forward, two back.

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.

(Sure, you could turn CheckVars off while writing, but that defeats  
the whole purpose, right?)

And yeah, it finds misspelled variable names, BUT it doesn't find  
where you typed the wrong variable or control or handler name, so it  
is arbitrarily useful. You still have to debug and test anyway, right?

AND, of course you don't ever misspell variable names anymore anyway,  
because you use ScriptPaint in Galaxy (a feature yours truly  
contributed ;-)! ScriptPaint (among many other benefits) mostly  
eliminates having to type a variable name (except for the first time)  
so it allows you to turn that burdensome CheckVars off and warp speed  
your development!


If anyone else has common timewasters and app bloating techniques,  
let's hear 'em!


hugs & K.I.S.S.es,

Josh



More information about the Use-livecode mailing list