Re: Variable names
Re: Variable names
- Subject: Re: Variable names
- From: Shane Stanley <email@hidden>
- Date: Thu, 13 Jan 2011 10:51:40 +1100
- Thread-topic: Variable names
On 13/1/11 9:38 AM, "BareFeetWare" <email@hidden>
wrote:
> 1. Yes, if you live in a vacuum and noone is EVER likely to read your script,
> you're not ever going to post it on this forum for help and you aren't going
> to read your script five minute, or five days or five months later, and you
> don't write anything complicated enough in which you might have to fix errors,
> then communication doesn't matter, and you could call all of your variable and
> handler names x1, x2, x3, x4 etc. I still think it's unnecessarily obfuscated,
> but no harm done since noone will ever have to understand what you wrote.
You're attacking a straw man. You're describing an extreme that no-one has
advocated. I'm merely suggesting that things like "repeat with i ..." often
do no harm, and that not every project needs to be approached with the same
discipline.
Incidentally, I have beside me a copy of Matt Neuburg's 'AppleScript: The
Definitive Guide', and I find myself referring to it from time to time. It
has quite a good reputation -- you should have a look some time. He does
quite a good job with x, y and even the occasional L.
(Heck, I see that Sanderson/Rosenthal and Soghoian/Cheeseman also use
"repeat with i...")
> 2. Yes, the goal is TOTAL minimized time. If it truly takes you precious
> minutes to think of a meaningful variable name and there is no time saving for
> you or anyone else to understand it later, then use whatever short names you
> like. But I expect that in almost all cases a more clearly written script will
> pay for itself 100 or 1000 fold.
This is religious talk. 1000 fold? So a script that took, say, 15 minutes to
write from scratch will be understandable in 1/1000th the time solely
because of variable names? Sorry, but these claims don't stand up to
scrutiny. You're arguing for rigid discipline, but you're doing it with
sloppy logic combined with faith, not facts.
>
> 3. Most arguments for short non-desriptive variable names seem to quote a line
> and say that in that context it's perfectly clear what the variable does. But
> my point is that a descriptive variable name makes it clear on EVERY line what
> the variable does.
No, it (hopefully) makes it clear what the variable contains. And sometimes
it can actually add to the confusion: a variable with an obvious meaning to
one person can have a totally different meaning to another. This happens
enough in English. And that ignores the cases where perhaps the name was
ill-advised -- but of course that never happens in real life.
Moreover, when scanning code it's possible for variable names to give a
context that colors your view of what's happening -- lots of complex
algorithms are written with simple variables for good reason, IMO: to keep
the focus on what is happening.
(Sorry to keep going on about this, but blame it on an anonymous anal
programmer whose work I recently had to deal with. Properties declaring
kConstants, g for globals and l for locals, all locals explicitly declared,
all broken into nice handlers, with each handler having a comment section
explaining what arguments it required and what it returned, "descriptive"
handler names so long I had to take a breath in the middle of reading them,
yada, yada. And actual implementation that had me wanting to poke my own
eyes out. If only the effort had been expended elsewhere...)
--
Shane Stanley <email@hidden>
'AppleScriptObjC Explored' <www.macosxautomation.com/applescript/apps/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden