On Jan 12, 2011, at 5:51 PM, Shane Stanley wrote: 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.
I agree with BareFeetWare, (with exception of the last section of the last sentence, and it's not a straw man, it's pretty flesh and blood.
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.
To beat that horse, I'm suggesting that it does matter, because we make and follow patterns in our life. Allowing yourself to resort to short and vague names make you always spend the time to look around to see what i really stood for.
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?
I'll agree with BareFeetWare again, because I made these changes because this is EXACTLY what I suffered through. Hours that were wasted debugging simply aren't hours anymore. I've got my Pope hat on and am firing up my bulletproof mercedes.
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.
I vote to make it PAINFULLY OBVIOUS what the variable does. That was my approach and as long as the name is now stupidly long the purpose of these labeled variables is to make it PAINFULLY OBVIOUS what the variable (and the handler name) is supposed to do.
Really, do you call your handlers M(), I(), J(), K()?
GetAvailableProcessorCores() sure beats G().
I took this, Painfully Obvious Names for Variables, Handlers and Classes™, approach to see what happened, oooooh, about 15 years ago and there is no way I'd ever consider dropping 5 characters of meaning to save a few keystrokes. 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.
Not if you spend time learning how to do it correctly. 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.
Not if you spend time learning how to do it correctly. (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...)
AHA! Yeah. l for locals? Argh. How about, "everything that is not preceded with a g or a p is a local by default"?
If your handler names become sentences in their own right, YOU'RE DOING IT WRONG!
When clarity and verbosity verges over onto the edge of stupidity, that's when it's gone over the line.
If he's got a dictionary next to his mac so he can look up new words to call his handlers, that's when it's over the line.
The purpose here is to be clear in coding and to have our code convey context to the things that we need context from when we need to think about them and make stuff work.
And structure your code. Do it for the children.
|