On 09/10/2012 17:28, Peter Haworth wrote:
On Tue, Oct 9, 2012 at 1:48 AM, Ben Rubinstein <benr...@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
_______________________________________________
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
