Mark Wieder wrote:
<sigh> Look, as a qa engineer let me state the truism that the earlier
in the development process you can find bugs, the cheaper it is to fix
them. The idea of enforcing explicit variable declarations is to catch
some bugs at compile time rather then waiting for them to appear at
runtime and force you to debug what happened.
Have you ever typed something like
"if theversion > 4.5 then"
instead of
"if the version > 4.5 then"
Easy enough to find if it's in front of you like that, but what if
it's buried in several hundred lines of code? With explicitVars
enabled the compiler will tell you what line of code failed when you
press the Apply button.
I believe in letting the compiler help me rather than fighting against
it. That's the whole reason I enable explicitVars. I can't count the
number of stupid typos I've caught this way in my code, in other
people's code, and in the IDE. Stuff that should never have gotten out
the door in the first place, and wouldn't if people just let the
compiler exercise some "discipline".
I agree with everything you wrote, but I still don't do it. :)
I think it's just a question of work style.
While everyone has typos in their code (though here I don't do
"theversion" as much as "teh version" <g>), in practice I find those are
a very slender minority of issues I encounter.
Far more frequent are logic errors, mismatched states, or other things
far beyond the scope of what explicitVars can help with.
One could argue that even if explicitVars helps with only a very slender
subset of my issues, it's still better than not using it at all, and I
would agree if it were not for this aspect of my workflow:
LiveCode is great for both prototyping and final deployment, so in the
early stages I often don't know exactly what my code will look like in
its final state; I try a few things, flesh them out, revise them, and
over time it becomes a finalized handler I can use as an internal API.
But that process often involves a lot of iteration, and along the way
things that began as params may become local vars, or even script-local
vars as I identify ways to leverage other handlers, or even custom props.
Taking full advantage of xTalk's inherent looseness, I can let this
process flow easily, adjusting things as I go freely with minimal
effort. This helps me keep my focus on the logic side of things, which
is for myself the greater weakness.
Typos are often found in unit testing right away, but logic errors due
to state assumptions can be far more difficult to pin down in the early
stages, so while it may be a cognitive weakness of mine I need to
reserve every brain cell I can for those.
If I also take the time to declare every variable (or, as we've seen,
most variables, since apparently not all require declaration under
explicitVars), that's just extra stuff to revise while I'm also revising
code. So I can see how it would be a benefit to some, but for me it just
slows me down.
I've been tempted after I finalize an API to go back and make it all
explicitVars-compliant, but inevitably there are other things on my
to-do list that take priority.
The cool thing about the way RunRev has revamped its use of explicitVars
in the IDE is that it lets both of us use whichever mode we find most
productive for our work style.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
