Good ways to overcomplicate your code and slow down development
josh at dvcreators.net
Thu Sep 14 15:07:20 CDT 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.
instead of simply:
set the uFlag of me to true
make everything a handler:
ON setUFlag pFlagValue
set the uFlag of me to pFlagValue
- 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
return the uFlag of me
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
(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
If anyone else has common timewasters and app bloating techniques,
let's hear 'em!
hugs & K.I.S.S.es,
More information about the use-livecode