Good ways to overcomplicate your code and slow down development

[Jerry Daniels]

Josh, you have a future making presentations! Very informative and  
entertaining.

Best,

Jerry Daniels

Artists, Consultants & Developers
http://www.daniels-mara.com/art
http://www.daniels-mara.com/services
http://www.daniels-mara.com

Skype: jerry.daniels


On Sep 14, 2006, at 3:07 PM, Josh Mellicker wrote:

> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>