Re: On variable naming... [was Re: AsciiNumber & AsciiCharacter Handlers]
Re: On variable naming... [was Re: AsciiNumber & AsciiCharacter Handlers]
- Subject: Re: On variable naming... [was Re: AsciiNumber & AsciiCharacter Handlers]
- From: email@hidden (Michael Sullivan)
- Date: Thu, 9 May 2002 16:12:05 -0400
- Organization: Society for the Incurably Pompous
has writes:
>
Arthur J Knapp wrote:
>
>> This is much more legible [1]. Not just to novices, but also to experienced
>
>> scripters and even the original author.
>
> If I am the original author of which you speak, I'm afraid I have to
>
>disagree, though I'm willing to admit that I may be unique in this regard.
Well, you're unique, but not in this regard.
>
This is telling me what a variable is, not what it does. Two different
>
things, and an important distinction that is easily overlooked.
>
I've seen various criticisms of the "code that fails to tell me anything I
>
didn't know already" tendency [best exemplified by the "set x to x + y --
>
this line adds y to x" school of commenting], but I can't recall seeing
>
anyone actively advocating it. (Not that this stops folks from using it in
>
their code, readability issues or no: short-term convenience often wins
>
over long-term security and common sense.)
I can't recall anyone advocating that style of comment here. God, I
hope not. I just got through editing out a whole pile of comments like
that from a script snippet I downloaded from somewhere.
>
This is not saying "NEVER use single letter variable names", merely to use
>
names that tell you something useful about the code; things that you won't
>
get otherwise without sitting down and grokking the lot.
Arthur's style is actually pretty close to Kernighan and Plauger in _the
Elements of Programming Style_, which is some folks (including mine)
Strunk and White of coding style. Reading their code is like a breath
of fresh air.
In any case, they specifically argue that single letter variable names
are just fine (and maybe better than long descriptive variable names)
when they are for standard idioms or used in fairly simple 1-5 line
functions that can be understood quickly.
If you're doing a math function, for instance. using a,b,c..., m,n,o...
or ...w,x,y,z is standard idiom and very readable. Much more so than
trying to do descriptive names.
To use a completely useless example:
on multiply(a, b)
set c to 0
repeat b times
set c to c + a
end repeat
return c
end multiply
--is a heck of a lot more readable than:
on multiply2(multiplicand, multiplier)
set product to 0
repeat multiplier times
set product to product + multiplicand
end repeat
return product
end multiply2
at least to me. I'm with Arthur on the example posted earlier as well.
To be honest, I think the line where smaller variable names help is
actually farther along in Applescript than in a very terse language like
C or Perl. There's something about a regular breakup between short and
long to make visual parsing easier. So in C (and especially perl!),
almost all operators and keywords will be terse, so long variable names
help distinguish variables visually.
In applescript just the opposite is true. Keywords and operators are
often long words or phrases, so having short, or single letter variable
names, helps visual parsing of a statement by making the word breaks
less homogeneous.
Obviously this breaks down when your function gets complicated enough,
or contains enough different variables, that you start having to spend
energy keeping track of what is what. At that point it becomes very
helpful for the variable names to do this for you.
But using a,b,c... for numeric arguments or i,j,k... for loop indices
are so normal and standard that, IMO, they remain very readable even
within quite complicated functions.
I also often use this idiom for handlers
on function(longDescriptiveArgumentName)
set a to longDescriptiveArgumentName
-- go on to do stuff with a
end function
This gets the description of how to work with the function into the
declaration line, so clients don't have to look at the code to figure
out how to call the function. But then if you *do* look at the code,
you don't have to deal with a 50 character variable name being used over
and over.
In any case, with everything I've seen of Arthur's, I pretty much agree
with his decisions on this front, and I've stolen a number of style
idioms for line break and tabbing decisions in applescript from him
because I find them very readable. I'm hard pressed to name anyone
who's applescript code presentation I like better.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.