Explicit Variables again

[Richard Gaskin]

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