Strict Compile Mode

[Ben Rubinstein]

On 09/10/2012 17:28, Peter Haworth wrote:
> On Tue, Oct 9, 2012 at 1:48 AM, Ben Rubinstein <benr_mc at cogapp.com> wrote:
>
>> It's effectively nullified by what I think is a bug
>> http://quality.runrev.com/**show_bug.cgi?id=3406<http://quality.runrev.com/show_bug.cgi?id=3406>
>>
>> It should be what you set so that you're always in 'explicit vars' mode by
>> default.  However, since the menu item "Variable checking" is sticky
>> between launches, it is now as far as I know meaningless.
>>
>
> OK, I now see there's another variable in play - the "Variable checking"
> item on the script Edit menu.  How does that interact with the "Strict
> Compile Mode" Preference setting, if at all?
>
> Still don't understand what "Variable Preservation" was supposed to do
> though.  It sounds like a different thing than "explicit variables" or
> "variable checking".

Sorry, I got confused - the preference "Strict Compilation" is affecting the 
same property (explicitVars) as the menu item "Variable checking", and made 
meaningless by that menu item being sticky between launches.  The preference 
"Variable Preservation" is something else altogether.  Tooltips might be 
useful in that Preferences dialog - does anyone know what "Interactive Find" does?

>> What would be really useful (as requested in above RQCC report) is to make
>> the setting sticky per script (with the preference then affecting new
>> scripts). This would enable one to be 'virtuous' by default, but not unduly
>> inconvenienced when working with old or contributed code.  The problem I
>> find is that if I have to fix eg a bug in a library, that's not 'explicit
>> vars clean', I need to switch off the setting.  I may then forget, and lose
>> the protection when I'm working on more modern scripts.
>>
>
> I had the same thought yesterday when I was ploughing through several
> thousand lines of code adding local statements!  It's pretty much an all or
> nothing situation unless you choose to temporarily switch off strict
> compile mode trusting that you'll remember to switch it back on again at
> the appropriate point.  Of course, if I'd used strict compile mode from the
> beginning, I wouldn't be complaining!

Yes you would, because other people (including, cough, RunRev in the IDE) 
didn't.  If you need to edit their code, you'll want this.  And I think of my 
younger self as "other people" anyway.  I'm really annoyed by the mess that 
guy left behind.

> Couple of other questions on variable conventions.
>
> Seems like starting handler local variable names with "t" is pretty common,
> although not sure what the "t" represents.  Is there a common convention
> for naming script local variables?

Several!

I use t as prefix for variables containing text, which in the nature of 
LiveCode is most of them, but allows me to distinguish i for integers, b for 
booleans, a for arrays.

I use s as prefix for script locals, g for globals, and k for constants.

Hence "sbKiosk" is a script-local variable whose value should be a boolean; 
"gaObject2Nationality" is a global variable whose value should be an array 
(and an array in which key is something that I'll understand by 'Object', the 
value as something which I'll recognise as Nationality); "tTerms" is a local 
variable with a string value.

Some people use "p" as a prefix for parameters in a function/handler - I think 
I probably should, but somehow I'm too old to change my ways now - if I did, 
I'd use it in addition to the type letter, eg now I know that "tTerms" is a 
local string variable, but can't tell if I declared it in the function body or 
if it was a parameter - "ptTerms" would be more explicit in that regard, and 
perhaps if I was really good I'd use "rtTerms" to indicate that it was a 
parameter passed by reference, which is arguably a more useful distinction to 
be aware of.

> I also noticed that some folks declare all their variables in one local
> statement at the top of a handler while others declare them in the body of
> the code right before they are used for the first time.  I'm guessing this
> is just a matter of personal style and preference but any advantages to
> either convention?

There probably isn't if you keep your handler definitions short, like you 
should; if like me you sometimes fail at this, then keeping your variables 
definitions close (and your enemies closer) at least helps to clarify that the 
some of them are only relevant in the latter part of the handler.  (Often 
where I do have declarations in the body of the code, it's when I've gone back 
over the work of my detested younger self with explicitVars on...

Ben