Long names are doom ?
00001111
Anybody use variables/names longer than 31 character
and finds it really useful ?
Then please respond why, where, when.
I have folks here in comp.lang.fortran who claim hard that they
- "never seen a well written, legible program
that uses any identifiers longer than 18-20 characters..".
- "long variables names are *hard* to read. And, you have to
read though all the characters of every instance of them...".
- "it degrades the legibility of a program to use identifiers that
can't be easily remembered...."
As a result, despite 90% of computer languages have long, very
long or 'infinite' identifiers, fortran folks seems plan to stay
with their 6...aargh ...sorry this was just not far ago... 31 character
limit intil year 3000.
cheers
Steve Wart
inSmalltalkHoweverItIsVeryCommonToHaveLongIdentifiers
Cheers,
Steve
"00001111" <0000...@my-deja.net> wrote in message
news:3B0DBCAB...@my-deja.net...
Donal K. Fellows
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Depends on what namespacing features the language in question has (noting
the newsgroups line.) With suitable namespaces, identifiers can be quite
short (less than fifteen characters... :^)
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
The problem with short variable names though is that they can be ever so
non-distinctive, and that can *really* kill legibility. IMO, identifier
naming needs taste and discretion; not too short, and not too long. I'd
be very surprised if there were any hard rules what is "short" or "long"
though...
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
That's utterly true. But shortness doesn't make for ease of memorisation
(FORTRAN's famous for library module names whose function can only be
deduced with the aid of a whole shelf of printed manuals.)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- If somebody in a suit or a uniform can sit you down and have you believe
every word he says, you've just surrendered your license to be a thinking
human being and traded it in for a zombie suit. -- mh...@prince.carleton.ca
Jim Lucas
> "00001111" <0000...@my-deja.net> wrote ...
>
> > Anybody use variables/names longer than 31 character
> > and finds it really useful ?
> >
> > Then please respond why, where, when.
>
> ICANSEEWHYTHATMIGHTBEAPROBLEMINFORTRAN
>
> inSmalltalkHoweverItIsVeryCommonToHaveLongIdentifiers
Yes, it makes a big difference if there's an obvious division into smaller
segments (anybody proposing that comp.lang.fortran be changed to
COMPLANGFORTRAN, or possibly COMPUTERLANGUAGEFORTRAN?). "Chunking" has been
established as an important element in perception, understanding, and memory.
It even makes it possible to debate whether a name like comp.lang.apl is a
single identifier or a sequence of three separate identifiers. And path names,
whether relative or absolute, are conceptually quite different from names like
DOWJONES30DAYMOVINGAVERAGE, or even DOW_JONES_30_DAY_MOVING_AVERAGE.
Reasonable constraints on the structure of a conceptual space of names can be
significantly affected by the available possibilities for naming data
structures and their parts.
So I think what I'm saying is that the question is not specific enough to be
given a definite answer, not even an opinion.
/Jim
Bryan Oakley
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
>
> Then please respond why, where, when.
> I have folks here in comp.lang.fortran who claim hard that they
>
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
I'd have to say that, as a general rule, this holds true. Long identifiers
are hard to read quickly. However, if there is a way to visually distinguish
chunks, or if a separation method carries it's own connotations (such as
with namespace separators), long names can be quite useful.
To be honest, I've rarely seen the need for 20 character identifiers,
*except* when you count namespace qualifiers.
I used to do FORTRAN, and even back then I tended to use longish names, but
only to the extent that I preferred 'counter' to 'cnt' or 'index' rather
than 'idx'. Those wacky FORTRAN people really seem to like short names, and
some of my coworkers would get annoyed at my use of 'something_clever'
rather than 'sclvr'.
The bottom line in all of this is clarity -- if long names make the code
more clear, use them. If they don't, don't. But don't abbrev. for abbrev's.
sake.
Daniel T.
One of my fellow employees almost quit over the issue the other day.
The boss had to work in some of his code (this programmer routinely goes
over 31 characters with his function names) and the boss got upset and
told the programmer to quit making his names so long. The programmer
then threatened to not do any work. I ended up being drawn into it
because my cube was next to his and he was siting the book "Refactoring"
which is a book that I recommended to him. I immediately took the middle
ground (especially after my boss said, "the code is too readable." :-)
I looked over said person's code and found that when you were reading
the body of a high level function, it was very easy to see what that
function was supposed to do, and the low level functions were so short
that it was obvious what they were supposed to do, but when you looked
at a function name out of context it would be a sentence fragment that
didn't make any sense at all (ie it didn't tell you what the function
itself was supposed to do.) Concequently, when going through the header
file (were talking C++ here) very little made sence. Keeping track of
the names was relatively easy because of VC++'s auto fillin feature.
I guess moderation is the key here. Make variables noun phrases and
functions verb phrases, don't put declaratives in the names and don't
abbreviate unless it is in common usage throughout the code and you
should be all right. I don't agree with people who remove all the vowles
from a word just to make it shorter. I also tend to think that the
length of the name should corospond to the name's scope. If the scope is
within the body of a small loop, then a one character name seems fine.
If the scope is global, then the name should be highly descriptive (and
therefore much longer.)
Jochen Schmidt
> Hi All,
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Yes. In Common Lisp long identifiers are often used.
Take a look in
"The Art of the Metaobject Protocol"
to see identifiers like:
generic-function-argument-precedence-order
update-instance-for-different-class
ensure-generic-function-using-class
and I've to say it is _good_ that they are so long.
Yes you could e.g say
genFunArgPrecOrder
But it is *much* less readable this way.
> Then please respond why, where, when.
> I have folks here in comp.lang.fortran who claim hard that they
>
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
Nonsense
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
see above Example "genFunArgPrecOrder"
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
>
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
6 characters? so my example would be like gFuAPO - yes _very_ readable!! ;-)
Regards,
Jochen
Ivan Tomek
class name by the following code fragment. The code can be shortened, but this
version shows very clearly what happens. I think that even a non-Smalltalk
person can se what is going on - partially because of names that programmers in
other languages might consider too long.
| longestName maxLength |
longestName := ''.
maxLength := 0.
Object withAllSubclasses do:
[:class | | newName newLength |
class isMeta
ifFalse: [
newName := class name.
newLength := newName size.
newLength > maxLength
ifTrue: [longestName := newName. maxLength := newLength]]].
longestName
By the way, the answer is ... (left as an exercise).
Ivan
Barry Margolin
Jochen Schmidt <j...@dataheaven.de> wrote:
>> - "long variables names are *hard* to read. And, you have to
>> read though all the characters of every instance of them...".
>
>see above Example "genFunArgPrecOrder"
>
>> - "it degrades the legibility of a program to use identifiers that
>> can't be easily remembered...."
It should probably be noted that the functions with long names are usually
*not* ones that are used frequently, so they don't impact readability or
writability very much.
And it's not uncommon to provide short abbreviations. In particular, note
that Scheme has "call-with-current-continuation" (30 characters), but it's
almost always invoked using its synonym "call/cc".
And when you're having an online discussion about a long-named function,
it's common to make use of an unofficial abbreviation. For instance, I've
seen many emails about the CLOS MOP that refer to things like
ENSURE-GENERIC-FUNCTION as E-G-F. This is not unlike legal documents that
introduce a shorthand (e.g. "the Company") for a long term that will be
used frequently (e.g. "The Widget Factory, Incorporated").
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Don Libes
> Then please respond why, where, when.
WHERE: Look at tkbiff (http://expect.nist.gov/tkbiff).
WHY: It creates variables named after incoming message-ids (which are
arbitrarily long, I think). Any alternative would be more indirect
and require more programming with no benefit. Debugging was easier
too.
WHEN: Right now. Looking at my current tkbiff process, my longest
variable name is 83 characters long. And it's really funny to look at
too. (But then so are Fortran variable names :-)
Same thing is true for window names. When the user pops up a window
to view a message. The internal name of the window uses the message-id.
Don
Jochen Schmidt
> I could not resist this. In Smalltalk, you can find for example the
> longest class name by the following code fragment. The code can be
> shortened, but this version shows very clearly what happens. I think that
> even a non-Smalltalk person can se what is going on - partially because of
> names that programmers in other languages might consider too long.
>
> | longestName maxLength |
> longestName := ''.
> maxLength := 0.
> Object withAllSubclasses do:
> [:class | | newName newLength |
> class isMeta
> ifFalse: [
> newName := class name.
> newLength := newName size.
> newLength > maxLength
> ifTrue: [longestName := newName. maxLength := newLength]]].
> longestName
>
> By the way, the answer is ... (left as an exercise).
In Common Lisp you can e.g. write
(let ((maxlen 0))
(do-all-symbols (symbol)
(setf len (max maxlen (length (symbol-name s)))))
maxlen)
To find the length of the longest accessable symbol of all packages.
Regards,
Jochen
Hartmann Schaffer
>ICANSEEWHYTHATMIGHTBEAPROBLEMINFORTRAN
why? the last time i looked at fortran you also could have written it as
i can see why that might be a problem in fortran
without changing the meaning of the program
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
morgan mair fheal
<j...@danbbs.dk> wrote:
>"Steve Wart" <sw...@deadspam.com> wrote ...
>> "00001111" <0000...@my-deja.net> wrote ...
>>
>> > Anybody use variables/names longer than 31 character
>> > and finds it really useful ?
>> >
>> > Then please respond why, where, when.
>> > I have folks here in comp.lang.fortran who claim....
>>
>> ICANSEEWHYTHATMIGHTBEAPROBLEMINFORTRAN
>>
>> inSmalltalkHoweverItIsVeryCommonToHaveLongIdentifiers
i lost track with fortan 90 but up to that point blanks could be freely
inserted anywhere except in strings
i use code things like
p r o g r a m m a i n
i n t e g e r p
100 f o r m a t ( *p=* i 1 0 )
d o 1 p = 1 , 1 0
p r i n t 1 0 0 , p
1 c o n t i n u e
e n d
Steve Wart
Holy smokes. I knew I stopped at FORTRAN 77 for a reason :)
Cheers,
Steve
"morgan mair fheal" <mair_...@www.yahoo.com> wrote in message
news:mair_fheal-25...@c8.ppp.tsoft.com...
lvi...@yahoo.com
According to Bryan Oakley <boa...@austin.rr.com>:
:I'd have to say that, as a general rule, this holds true. Long identifiers
:are hard to read quickly.
I have always found it even harder to _compare_ two similarly named 20-50
or more character symbols. I mean is
THISISRIDICULOUS += THISISRIDICILOUS * 2 ;
supposed to be two different variables, or a typo by the programmer?
For that matter, I don't care to type all those letters; so I generally
don't use variables longer than 6-12 characters myself. I just use
documentation/comments to document what the variables are supposed to mean.
The main place I would consider using really long variable name is if
in some small piece of code I was going to need a LOT (ie dozens or
more) of unique variables...
--
--
"See, he's not just anyone ... he's my son." Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
Stwo
<lvi...@yahoo.com> wrote in message news:9env7e$1t7$3...@srv38.cas.org...
>
>
> THISISRIDICULOUS += THISISRIDICILOUS * 2 ;
Reminds me of
http://mindprod.com/unmain.html
Stu
Pierre R. Mai
> According to Bryan Oakley <boa...@austin.rr.com>:
> :I'd have to say that, as a general rule, this holds true. Long identifiers
> :are hard to read quickly.
>
> I have always found it even harder to _compare_ two similarly named 20-50
> or more character symbols. I mean is
>
> THISISRIDICULOUS += THISISRIDICILOUS * 2 ;
>
> supposed to be two different variables, or a typo by the programmer?
This is more a function of using all-caps, non-separated symbols
rather than the length of the symbols in question (though greater
length obviously exacerbates the problem). And then there's the
problem of difficult to spell words in symbols, e.g. ridiculous, which
many people misspell easily.
Still:
this-is-ridiculous += this-is-ridiclous * 2
is better to check/detect, even with ridiculous.[1]
But the real solution to this problem, as well as the typing effort
you mentioned, are editors that offer (file-independent) completion
features, based on already used symbols, thereby both preventing
deviant spellings from cropping up, and having to manually enter the
symbol on any of its subsequent uses.
Regs, Pierre.
Footnotes:
[1] Actually this particular instance should be written as
this-is-ridiculous *= 3
or some such in the first place. The use of - as a non-separating
symbol component probably doesn't work well in an infix language,
where you'd probably prefer _. In Common Lisp, where - works well,
because of prefix syntax, the form would be written as
(multiplyf this-is-ridiculous 3)
Given the in-place mutator multiplyf, which can be defined as
(define-modify-macro multiplyf (&rest factors) *)
(Yes the f suffix is an artifact of prior generations of Lisps, where
shorter symbol names were more common, not because of limitations to
the language processors, but more due to the inadequacies of input
devices).
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Carl Gay
> Footnotes:
> [1] Actually this particular instance should be written as
>
> this-is-ridiculous *= 3
>
> or some such in the first place. The use of - as a non-separating
> symbol component probably doesn't work well in an infix language,
> where you'd probably prefer _. In Common Lisp, where - works well,
> because of prefix syntax, the form would be written as
Use of '-' in identifiers has honestly never been a problem for me in Dylan. It simply requires that you add whitespace around use of operators (which I would argue should be done anyway):
let head-length = head-width * 2;
But I can't remember a single time I've gotten confused and read something like the above as "head - width * 2".
On the other hand I (and most of my collegues) come from a Common Lisp background so we're pretty used to seeing things like *my-dog-has/had-fleas* as identifiers. I have to admit that I find it quite difficult to read Java code where the author doesn't put whitespace around operators, so it seems quite possible that someone coming from a Java, C, C++ background would have a hard time with it for a while if they're used to that style.
Donal K. Fellows
> Reminds me of http://mindprod.com/unmain.html
Amusing, though I've seen worse in production code. One of the most painful
recent experiences was encountering a set of classes which were all derived
from a superclass which contained an array of references (this was Java)
which allowed for the construction of every possible reference of one object
to another. Every object was kept in a list of all the objects which were
clones of each other, which had the same user type (helpfully, these did not
coincide at all, and had no resemblence to the types of the classes), which
were in the same list, the same tree, or whatever other collection. Indexes
into the array were done by named constants, but these were in turn spread
across classes in several packages, and usually referred to by their fully-
qualified name (helpfully 8 or 9 namespace-elements long...)
Needless to say, I've simply dropped all hope of using the code.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- What's the reason of long discussions, if at the end someone says, "we have
not yet thought about it..." -- Andreas Leitgeb <a...@pc7499.gud.siemens.at>
Pekka P. Pirinen
> Yes. In Common Lisp long identifiers are often used.
>
> Take a look in
> "The Art of the Metaobject Protocol"
> to see identifiers like:
>
> generic-function-argument-precedence-order
> update-instance-for-different-class
> ensure-generic-function-using-class
You don't need to find a book (even though it is a good book);
UPDATE-INSTANCE-FOR-DIFFERENT-CLASS made it into the CL standard.
It's not even the longest standard name, there are 8 longer ones, up
to 38 characters.
Looking at a CL implementation I happen to have here (LispWorks), the
longest symbol in it, discounting automatically generated ones, is
CAPI:*MAXIMUM-NUMBER-OF-EDGES-TO-DYNAMICALLY-TRACK-DURING-GRAPH-MOTION*.
That could be shorter, but I don't see anything hard to read about it.
--
Pekka P. Pirinen, Harlequin Limited, Cambridge, UK
There may be no candidates you want to vote for, but there are
certainly some you want to vote *against*.
Brian Campbell
> In article <9elpia$1f19$1...@ID-22205.news.dfncis.de>,
> Jochen Schmidt <j...@dataheaven.de> wrote:
> >> - "long variables names are *hard* to read. And, you have to
> >> read though all the characters of every instance of them...".
> >
> >see above Example "genFunArgPrecOrder"
> >
> >> - "it degrades the legibility of a program to use identifiers that
> >> can't be easily remembered...."
>
> It should probably be noted that the functions with long names are usually
> *not* ones that are used frequently, so they don't impact readability or
> writability very much.
>
> And it's not uncommon to provide short abbreviations. In particular, note
> that Scheme has "call-with-current-continuation" (30 characters), but it's
> almost always invoked using its synonym "call/cc".
>
> And when you're having an online discussion about a long-named function,
> it's common to make use of an unofficial abbreviation. For instance, I've
> seen many emails about the CLOS MOP that refer to things like
> ENSURE-GENERIC-FUNCTION as E-G-F. This is not unlike legal documents that
> introduce a shorthand (e.g. "the Company") for a long term that will be
> used frequently (e.g. "The Widget Factory, Incorporated").
It should also be noted that in Dylan, there is no global namespace, and when
importing bindings from other modules, you can rename them however you like. So
in order to have fully descriptive names module authors can export nice, long
names, but when importing them you can abbreviate them however you like.
-- Brian Campbell
To really contact me, mail me at lambda (at) world (dot) std (dot) com
Adam Lazer
possibly confusing. Usually long names
are a result of corporate dictum regarding name formation.
Joe
00001111 <0000...@my-deja.net> wrote in message
news:3B0DBCAB...@my-deja.net...
Kaz Kylheku
wrote:
> Hi All,
>
> Anybody use variables/names longer than 31 character
>and finds it really useful ?
>
>Then please respond why, where, when.
>I have folks here in comp.lang.fortran who claim hard that they
>
>- "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
However, that opinion means nothing. It's conceivable that a program which
generates code might require that identifiers be distinguished by more than
their first 20 characters, for whatever reason. For example, it may lexically
encode the structure of some abstract entity into the name, using an
explicit representation.
Readability arguments assume that the programmer is a human being, which is
naive if you are writing a language specification or implementation.
(Naivete in comp.lang.fortran? Say it ain't so! :)
Mark van Gulik
k...@ashi.footprints.net wrote on 5/31/01 1:40 AM:
Code generators should go to great lengths (pun not intended) to produce
names that are as meaningful as possible. Sometimes this means including
lots of information in the name and sometimes it means eliding as much noise
as possible. I've seen identifiers bigger than 1K using templates in C++.
Not that those particular names needed to be entered (or even examined in
most cases) by a human, but it was essential information for those crappy
ancient linkers.
In Smalltalk, the byte-transfer operation is named
#replaceFrom:to:with:startingAt:. This is 31 characters on the nose. In
C/C++ it is called strncpy (basically). While everyone is entitled to their
own opinion, no matter how ridiculous, I assume most sane people would
prefer something closer to the Smalltalk name than the C nm (you can't
really call something without vowels a name, can you? (yes, I know about
that Pepsi contest that a Mr. Ng tried to cash in on (and yes, I know about
the artist formerly known as the artist formerly known as Prince who was a
dingbat for a while))).
Maybe we should do cultural exchange and rename those languages _Smltk and
ThirdLetterOfAlphabet.
Donal K. Fellows
> Maybe we should do cultural exchange and rename those languages _Smltk and
> ThirdLetterOfAlphabet.
.sigged!
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
Kaz Kylheku
>In Smalltalk, the byte-transfer operation is named
>#replaceFrom:to:with:startingAt:. This is 31 characters on the nose. In
>C/C++ it is called strncpy (basically). While everyone is entitled to their
>own opinion, no matter how ridiculous, I assume most sane people would
>prefer something closer to the Smalltalk name than the C nm (you can't
>really call something without vowels a name, can you?
I'd prefer the operation's name to not include redundant information about the
parameters.
Here, it's clear that the operation here is ``replace'', with parameters
``from'', ``to'', ``width'' and ``startingAt''.
Ivan Tomek
desirable. However, compare the following message/function calls
'abcdefg' replace(3 4 'xx' 2)
with
'abcdefg' replaceFrom: 3 to: 4 with: 'xx' startingAt: 2
(whatever the syntax and semantics might be). Isn't the second infinitely more
clear? Isn't it infinitely easier to make a mistake (accidentally misplace the
arguments) in the first formulation than in the second?
Isn't it much more natural?
Ivan
Kaz Kylheku
>If I understand you correctly, you think that multi-keyword names are less
>desirable. However, compare the following message/function calls
>
>'abcdefg' replace(3 4 'xx' 2)
>
>with
>'abcdefg' replaceFrom: 3 to: 4 with: 'xx' startingAt: 2
>
>(whatever the syntax and semantics might be). Isn't the second infinitely more
>clear?
The second is clear, but note that the operation identifier is
``replaceFrom''. It's not really a multi-keyword name, but an operation
with a keyword-value argument list. I don't see a long identifier
anywhere.
>Isn't it infinitely easier to make a mistake (accidentally misplace the
>arguments) in the first formulation than in the second?
>Isn't it much more natural?
It is; that's why it's nice to have keyword-value arguments in a programming
language (e.g. Common LISP).
Darren New
> >'abcdefg' replaceFrom: 3 to: 4 with: 'xx' startingAt: 2
> The second is clear, but note that the operation identifier is
> ``replaceFrom''.
Well, no, not in Smalltalk.
'abcdefg' replaceFrom: 3 to: 4 with: 'xx'
is a completely different procedure from what's above.
> It's not really a multi-keyword name, but an operation
> with a keyword-value argument list. I don't see a long identifier
> anywhere.
Smalltalk scatters the function name betwixt the arguments, basically.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
This is top-quality raw fish, the Rolls-Rice of Sushi!
Eric Clayberg
news:slrn9hdn...@cafe.net...
> On Thu, 31 May 2001 21:48:39 -0300, Ivan Tomek <ivan....@acadiau.ca>
wrote:
> >If I understand you correctly, you think that multi-keyword names are
less
> >desirable. However, compare the following message/function calls
> >
> >'abcdefg' replace(3 4 'xx' 2)
> >
> >with
> >'abcdefg' replaceFrom: 3 to: 4 with: 'xx' startingAt: 2
> >
> >(whatever the syntax and semantics might be). Isn't the second infinitely
more
> >clear?
>
> The second is clear, but note that the operation identifier is
> ``replaceFrom''.
No. The method that is being sent is "replaceFrom:to:with:startingAt:" with
four arguments. That is standard Smalltalk keyword syntax.
> It's not really a multi-keyword name
Actually, that is exactly what it is.
-Eric
Andreas Leitgeb
>> >'abcdefg' replaceFrom: 3 to: 4 with: 'xx' startingAt: 2
>Well, no, not in Smalltalk.
>
>'abcdefg' replaceFrom: 3 to: 4 with: 'xx'
>
>is a completely different procedure from what's above.
does that mean, that
'abcdefg' replaceFrom: 3 to: 4 startingAt: 2 with: 'xx'
(two of the arguments swapped) would also be a different proc
in smalltalk ?
I think I prefer Tk-commands handling of key-value pairs
(button .b -width 42 -command {puts 42} ...)
or python's (every proc can be called with argumentname-value-pairs
rather than a predefined order of args
--
Newsflash: Sproingy made it to the ground !
read more ... <http://avl.enemy.org/sproingy>
Richard.Suchenwirth
>
> On Fri, 01 Jun 2001 01:44:34 GMT, Darren New <dn...@san.rr.com> wrote:
> >> >'abcdefg' replaceFrom: 3 to: 4 with: 'xx' startingAt: 2
> >> ... but note that the operation identifier is ``replaceFrom''.
> >Well, no, not in Smalltalk.
> >
> >'abcdefg' replaceFrom: 3 to: 4 with: 'xx'
> >
> >is a completely different procedure from what's above.
>
> does that mean, that
> 'abcdefg' replaceFrom: 3 to: 4 startingAt: 2 with: 'xx'
> (two of the arguments swapped) would also be a different proc
> in smalltalk ?
>
> I think I prefer Tk-commands handling of key-value pairs
> (button .b -width 42 -command {puts 42} ...)
>
> or python's (every proc can be called with argumentname-value-pairs
> rather than a predefined order of args
>
wrapped around the built-in 'string replace' (which uses positional
arguments):
proc replace {s args} {
array set opt [concat {-from 0 -to end -with ""} $args]
string replace $s $opt(-from) $opt(-to) $opt(-with)
}
% replace abcdefg -from 3 -to 4 -with xx
abcxxfg
Keywords can come in any order or be omitted (in which case defaults
apply).
Flaw: "Undefined" keywords, e.g. typos (-wiht), are not detected...
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
Siemens Dematic AG, PA RC D2, Buecklestr.1-5, 78467 Konstanz,Germany
Personal opinions expressed only unless explicitly stated otherwise.
Darren New
> does that mean, that
> 'abcdefg' replaceFrom: 3 to: 4 startingAt: 2 with: 'xx'
> (two of the arguments swapped) would also be a different proc
> in smalltalk ?
That's correct.
The name of the function is actually "replaceFrom:to:startingAt:with:".
Normally, you wouldn't name a different function with the arguments
switched around. Just too confusing.
Just like in Tcl, the ReadSocket proc is different from the SocketRead
proc, and you probably wouldn't define both of them in the same program.
00001111
00001111 wrote:
> Hi All,
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Christian Brolin (comp.lang.functional) wrote the program
which abbreviates identifiers.
In fact if you look deeply you start to smile.
This definitely is not human respond on these 3 initial claims but
Computer's one where even 'cyber brain' laughs full of irony.
Christian Brolin (comp.lang.functional) wrote:
>
> I have a program that can abbreviate names, e.g.:
>
> [(len,abbreviate len "Anybody_use_names_longer_than_31_characters")
> | len <- [43,42..10]];
> [(43, "Anybody_use_names_longer_than_31_characters"),
> (42, "Anybody_use_names_longer_than_31_charactrs"),
> (41, "Anybody_use_names_longer_than_31_charctrs"),
> (40, "Anybody_use_names_longer_than_31_chrctrs"),
> (39, "Anybody_use_names_longer_thn_31_chrctrs"),
> (38, "Anybody_use_names_longr_thn_31_chrctrs"),
> (37, "Anybody_use_names_lngr_thn_31_chrctrs"),
> (36, "Anybody_use_nams_lngr_thn_31_chrctrs"),
> (35, "Anybody_use_nms_lngr_thn_31_chrctrs"),
> (34, "Anybdy_use_nms_lngr_thn_31_chrctrs"),
> (33, "Anbdy_use_nms_lngr_thn_31_chrctrs"),
> (32, "Anbdy_us_nms_lngr_thn_31_chrctrs"),
> (31, "Anbd_us_nms_lngr_thn_31_chrctrs"),
> (30, "Anbd_us_nms_lngr_thn_31chrctrs"),
> (29, "Anbd_us_nms_lngr_thn31chrctrs"),
> (28, "Anbd_us_nms_lngrthn31chrctrs"),
> (27, "Anbd_us_nmslngrthn31chrctrs"),
> (26, "Anbd_usnmslngrthn31chrctrs"),
> (25, "Anbdusnmslngrthn31chrctrs"),
> (24, "Anbdusnmslngrthn31chrctr"),
> (23, "Anbdusnmslngrthn31chrct"),
> (22, "Anbdusnmslngrthn31chrc"),
> (21, "Anbdusnmslngrthn31chr"),
> (20, "Anbdusnmslngrthn31ch"),
> (19, "Anbdusnmslngrthn31c"),
> (18, "Anbdusnmslngrthn31"),
> (17, "Anbdusnmslngrthn3"),
> (16, "Anbdusnmslngrthn"),
> (15, "Anbdusnmslngrth"),
> (14, "Anbdusnmslngrt"),
> (13, "Anbdusnmslngr"),
> (12, "Anbdusnmslng"),
> (11, "Anbdusnmsln"),
> (10, "Anbdusnmsl")
>
>
Then let's continue little bit
(9,...)
(8,...)
(7,...)
(6,...)
(5,...)
(4,...)
(3,...)
(2,An)
(1,A)
(0, ERROR: FORTRAN NAME IS TOO SHORT.
CHOOSE IT BETWEEN 1 and 6 CHARACTERS. STOP. END)
Bravo Christian ! That's just real Classics!
Christian Brolin (comp.lang.functional) wrote:
>
>
>
>
>
>
>
> Code:
>
> abbreviate :: Int -> String -> String
> abbreviate maxlen
> = truncate
> . reverse
> . remove wordSeparators
> . remove allButFirstVowels
> . remove adjacentDuplicates
> . remove vowelsEmbeddedInConsonants
> . reverse
> where
> isVowel c = elem c "aeiouy"
> isConsonant c = isAlpha c && not (isVowel c)
> remove rule name = remove' (length name) rule name
> remove' _ _ [] = []
> remove' len rule name
> | len > maxlen = let (keep,del,test) = rule name
> in keep ++ remove' (len - del) rule test
> | otherwise = name
> vowelsEmbeddedInConsonants (f:e:d:rest)
> | isConsonant d && isVowel e && isConsonant f = ([f],1,d:rest)
> | otherwise = ([f],0,e:d:rest)
> vowelsEmbeddedInConsonants name = (name,0,[])
> adjacentDuplicates (e:d:rest)
> | d==e = ([],1,d:rest)
> | otherwise = ([e],0,d:rest)
> adjacentDuplicates name = (name,0,[])
> allButFirstVowels (e:d:rest)
> | isAlpha d && isVowel e = ([],1,d:rest)
> | otherwise = ([e],0,d:rest)
> allButFirstVowels name = (name,0,[])
> wordSeparators (u:rest)
> | u=='_' = ([],1,rest)
> | otherwise = ([u],0,rest)
> wordSeparators name = (name,0,[])
> truncate = take maxlen
>
> --
> Christian Brolin -> Det är fult att peka
Randy A. Ynchausti
> > Anybody use variables/names longer than 31 character
> > and finds it really useful ?
I am not sure if I have lost the full context of what is going on here --
but I thought I would offer this perspective:
The Smalltalk culture places a high value on code that is expressive, easy
to read, and self documenting. These values are hard to achieve when good
names are not chosen for Class Categories, Classes, Instances Variables,
Protocols, Methods, etc. If the code is more expressive, easy to read, and
self documenting with variable names longer than 31 characters, then I do
the typing and use long names.
For example, consider the following method snippet:
--------------------------------------------------------------
computeNegativeMachinePrecision
.
.
.
[ ... ] whileFalse: [ negativeMachinePrecision := negativeMachinePrecision
* anInverseRadix ]
----------------------------------------------------------------
The unit-test for this code might look like:
---------------------------------------------------------------
.
.
.
self assert: ( testObject negativeMachinePrecision isNil ).
testObject computeNegativeMachinePrecision.
self assert: ( testObject negativeMachinePrecision > self
expectedNegativeMachinePrecisionLimit )
---------------------------------------------------------------
There are some long names in these code snippets. However, note that they
were chosen to help make the code's intent obvious. Try substituting
"ngtvMchnPrcsn" for "negativeMachinePrecision." Six months latter, I would
likely have to study the code for some time to figure out what
"ngtvMchnPrcsn" really represented.
So my point is [translation: I believe] that length of variable names, etc.,
is not as important as selecting descriptive names that are the most
expressive, easy to read, and self documenting. And I use names longer than
31 characters more often that one would think to achieve those qualities in
my code.
Regards,
Randy
Dave Harris
> self assert: ( testObject negativeMachinePrecision > self
> expectedNegativeMachinePrecisionLimit )
On the other hand, there is a lot of redundancy in that repetition of
"negativeMachinePrecision". Ideally we would factor out the common part
somehow. I don't mean abbreviations like "ngtvMchnPrcsn" so much as names
like "expectedResultLimit". That the result is a negativeMachinePrecision
ought to be obvious from the context. If it is not obvious, how can we
make it obvious?
Long names are sometimes a code smell that suggests we are not getting
enough milage out of the context. Maybe it means we are trying to do too
much in one object. Creating a new class is a way of creating a more
specific context, which allows the names used in that class to be
shorter. For this reason I think well-written OO code has less trouble
with long names than, say, C.
Issues of namespace and scope (and redundancy) are at the core of what
OO, and programming, is about. Which isn't to say that classes are the
best approach, of course. Both C++ and Smalltalk have added namespaces
alongside classes. (I'm not sure where the other languages stand; this
article is being posted to 6 newsgroups.)
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Eric Landau
bran...@cix.co.uk wrote:
|On the other hand, there is a lot of redundancy in that repetition of
|"negativeMachinePrecision". Ideally we would factor out the common part
|somehow. I don't mean abbreviations like "ngtvMchnPrcsn" so much as names
|like "expectedResultLimit". That the result is a negativeMachinePrecision
|ought to be obvious from the context. If it is not obvious, how can we
|make it obvious?
|
|Long names are sometimes a code smell that suggests we are not getting
|enough milage out of the context. Maybe it means we are trying to do too
|much in one object. Creating a new class is a way of creating a more
|specific context, which allows the names used in that class to be
|shorter. For this reason I think well-written OO code has less trouble
|with long names than, say, C.
This entire discussion seems to have overlooked the existence of
comments. If you're going to use a variable name repeatedly but don't
want to have to type something long and descriptive every time, a
simple "/* NMP = negative machine precision */" the first time the
variable name NMP appears in the code goes an awfully long way towards
making it understandable.
Eric Landau ela...@cais.com
APL Solutions, Inc. ela...@acm.org
1107 Dale Drive (301) 589-4621
Silver Spring MD 20910-1607 Fax (301) 589-4618
Andreas Leitgeb
>That's correct.
>The name of the function is actually "replaceFrom:to:startingAt:with:".
For most "non-native" smalltalkers, key-value-pairs imply
swap-invariance. I guess, "native" smalltalkers don't see this
as key-value-pairs ...
Its something one has to get used to.
>Just like in Tcl, the ReadSocket proc is different from the SocketRead
>proc, and you probably wouldn't define both of them in the same program.
"ReadSocket" is one identifier, that is never taken apart.
If someone defined a command in tcl that takes "-key value" style
arguments, and strictly specified the order of the keys, this would
still be a perfectly valid command, but would feel very alien to Tcl'ers.
babel rulz.
Duane Rettig
> In article <memo.20010602...@brangdon.madasafish.com>,
> bran...@cix.co.uk wrote:
>
> |On the other hand, there is a lot of redundancy in that repetition of
> |"negativeMachinePrecision". Ideally we would factor out the common part
> |somehow. I don't mean abbreviations like "ngtvMchnPrcsn" so much as names
> |like "expectedResultLimit". That the result is a negativeMachinePrecision
> |ought to be obvious from the context. If it is not obvious, how can we
> |make it obvious?
> |
> |Long names are sometimes a code smell that suggests we are not getting
> |enough milage out of the context. Maybe it means we are trying to do too
> |much in one object. Creating a new class is a way of creating a more
> |specific context, which allows the names used in that class to be
> |shorter. For this reason I think well-written OO code has less trouble
> |with long names than, say, C.
>
> This entire discussion seems to have overlooked the existence of
> comments. If you're going to use a variable name repeatedly but don't
> want to have to type something long and descriptive every time, a
> simple "/* NMP = negative machine precision */" the first time the
> variable name NMP appears in the code goes an awfully long way towards
> making it understandable.
In a language which allows self-commenting through descriptive names,
such a commenting style is superfluous, which make it less useful, and
even dangerous:
1. Such comments are only visible at the point at which they are made,
and are not easy to reference from every point in the code where the
variable is referenced.
2. Comments have syntax associated with their boundaries, and are thus
never as compact as the equivalent identifier.
3. Comments which describe identifiers are not normallized (because
anything can go into a comment), so an automatic program scanner cannot
parse them programmatically.
4. Superfluous comments tend to age more slowly than code, and thus
eventually become downright lies.
Please note that I am not bashing well-placed comments. The technique you
described is a good one for languages which are unfortunate to have
such limitations as to make the comments necessary. However, many of the
languages in this cross-posted article allow many characters in a name, and
so such a commenting style is superfluous, and thus discouraged. That is
likely why nobody has mentioned such an otherwise apparently obvious coding
style.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Georg Bauhaus
: 3. Comments which describe identifiers are not normallized (because
: anything can go into a comment), so an automatic program scanner cannot
: parse them programmatically.
Need not be a comment, some languages allow local renaming,
fully checked during translation.
: However, many of the
: languages in this cross-posted article allow many characters in a name, and
: so such a commenting style is superfluous, and thus discouraged.
decl temporary_bean_index: integer := 0;
while temporary_bean_index < 100 do
bean_counter[temporary_bean_index] :=
bean_counter[temporary_bean_index] + beans_counted(temporary_bean_index);
temporary_bean_index := temporary_bean_index + 1;
end;
vs. the obvious.
So your rule is not so universal?
Georg Bauhaus
---
Microsoft Windows--a whole new perspective on information hiding!
Randy A. Ynchausti
> |On the other hand, there is a lot of redundancy in that repetition of
> |"negativeMachinePrecision".
I guess I don't understand your use of the term "redundancy." What is the
difference between repeating a variable named "a" or a variable named
"negativeMachinePrecision?"
> Ideally we would factor out the common part
> |somehow. I don't mean abbreviations like "ngtvMchnPrcsn" so much as names
> |like "expectedResultLimit". That the result is a negativeMachinePrecision
> |ought to be obvious from the context. If it is not obvious, how can we
> |make it obvious?
Sorry, -- your point is completely vague and lost on me!
> |Long names are sometimes a code smell that suggests we are not getting
> |enough milage out of the context.
I have not experienced this. I am currently refactoring some code where the
original developer used names like "tmp" and "oc." If there is such a thing
as code smell -- it is certainly more prevalent in the use of these types of
names where the original developer understood the context, but failed to
communicate it in the code.
> |Maybe it means we are trying to do too much in one object.
Once again -- I don't get this point -- in the context of this discussion!
How is the choice of a name related to how much work or code is implemented
in one object?
> |Creating a new class is a way of creating a more
> |specific context, which allows the names used in that class to be
> |shorter.
This correlation is secondary at best.
> |For this reason I think well-written OO code has less trouble
> |with long names than, say, C.
I don't quite agree with this conclusion. I don't think it is valuable to
try an eliminate the number of characters that one types for the name of a
variable. The most important quality one can have in their code is
expressiveness and clarity. So I recommend that developers select names
that make the code easy to read, simple, expressive and clear -- no matter
how long the names are or are not.
> This entire discussion seems to have overlooked the existence of
> comments.
If you use expressive names you rarely need comments. I only use comments
where the code does not clearly express its intent (because it is
implemented for speed/performance or something like that). I do not use
comments to document a name just to save me some typing -- but then again, I
type using eight fingers and two thumbs.
> If you're going to use a variable name repeatedly but don't
> want to have to type something long and descriptive every time, a
> simple "/* NMP = negative machine precision */" the first time the
> variable name NMP appears in the code goes an awfully long way towards
> making it understandable.
Don't you think that this recommendation is counter-productive. If I am
looking at some code and first have to scan it to find the comment to
decipher what the acronym names, I think it is a reasonable conclusion that
the code is not as clear or easy to read. Futhermore, this practice leads
some developers to chose bad acronyms. For example:
// nmm -- number of man months
// mmm -- many man months
// mmn -- many man names
// nnn -- number of nanny names
Try deciphering code with these acronyms repeated several times. In the
end, more expressive names, no matter their length result in higher quality
source code, in my opinion.
Regards,
Randy
Mark Wilden
news:9fil0q$mlk$1...@a1-hrz.uni-duisburg.de...
>
> decl temporary_bean_index: integer := 0;
> while temporary_bean_index < 100 do
> bean_counter[temporary_bean_index] :=
> bean_counter[temporary_bean_index] +
beans_counted(temporary_bean_index);
> temporary_bean_index := temporary_bean_index + 1;
> end;
>
> vs. the obvious.
Yes, you're right. Names like sfjaer23409vxcvdfgeqrtq3tjtjcfb_0rtert also
completely refute the "long name" rule.
Please.
ignace saenen
quite.
further more, commenting on the name of variables is not what comments
ought to be used for in the first place imho. generally, algorithmic
details, functionalism and consequences (pre and post) are described in
the code by use of comments, but certainly not why we`re actually
looking at 'nnn' instead of 'namedNannyNumber'.. that`s just cosmetics,
not very interesting.
Duane Rettig
> Duane Rettig (du...@franz.com) wrote:
>
>
> : 3. Comments which describe identifiers are not normallized (because
> : anything can go into a comment), so an automatic program scanner cannot
> : parse them programmatically.
>
> Need not be a comment, some languages allow local renaming,
> fully checked during translation.
Precisely my point; a comment cannot be regularized/normalized in the
same manner as renaming, and thus languages which allow local renaming
are close to the category of languages which allow long names outright.
The only problem I have with renaming is that at some point there will
eventually be a name clash because of the potential many-to-one mappings
of names onto smaller names.
I used to work on a system with a fortran-centric linker (HP/1000 RTE-IVb
operating system), and although their C compiler could distinguish more
than 6 characters, there would be conflicts if any two identifiers were
made external that had the first 6 characters the same. So programming
in HPC was not a problem; linking multiple modules together was a problem.
I view this as an example of local renaming.
> : However, many of the
> : languages in this cross-posted article allow many characters in a name, and
> : so such a commenting style is superfluous, and thus discouraged.
>
> decl temporary_bean_index: integer := 0;
> while temporary_bean_index < 100 do
> bean_counter[temporary_bean_index] :=
> bean_counter[temporary_bean_index] + beans_counted(temporary_bean_index);
> temporary_bean_index := temporary_bean_index + 1;
> end;
This looks to me to be a fine example of a well-written piece of
code, and even though I don't know precisely which language it is,
I can understand it perfectly, even though it has no comments.
> vs. the obvious.
The obvious? Are you saying that you would prefer to do it differently
than your example above?
> So your rule is not so universal?
I don't understand this question. What are you asking or implying?
Pierre R. Mai
> If you use expressive names you rarely need comments. I only use comments
> where the code does not clearly express its intent (because it is
> implemented for speed/performance or something like that). I do not use
> comments to document a name just to save me some typing -- but then again, I
> type using eight fingers and two thumbs.
Furthermore any reasonable environment will assist you in inserting
repeated identifiers (and this functionality has been part of
environments for several decades now). This reduces typing effort,
and reduces trivial mistyping-mistakes. And those mechanisms
typically work even better if your identifiers are longer on average,
because this increases the distance between valid identifiers.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Michael T. Richter
Hash: SHA1
"Eric Landau" <ela...@cais.com> wrote in message
news:9fguhf$1h4...@newsreader.cais.net...
> This entire discussion seems to have overlooked the existence of
> comments. If you're going to use a variable name repeatedly but don't
> want to have to type something long and descriptive every time, a
> simple "/* NMP = negative machine precision */" the first time the
> variable name NMP appears in the code goes an awfully long way towards
> making it understandable.
Two words: code browser.
If I'm on a large, complex project your solution is unworkable. I'm likely
using some kind of browser to navigate the source. If I click on an object
name to see its members and the names I see are things like "NMP", I'm
going to start practicing voodoo in the vain hopes that the person who made
that object succumbs to a nasty curse because the code browser will
definitely not show me that comment.
I'd rather type out the long names (especially in an editor with the smarts
to autocomplete names) than have to go hunting for comments which may or
may not accurately reflect the actual state of code.
- --
Michael T. Richter
"Be seeing you."
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOx+dr7TM3QkE7U/oEQJcmgCeP0XDj230ShJM9pjMewLOzOmWD+gAn3Dz
kL59vJVF3jfxg9t7+X0pslzf
=YwF0
-----END PGP SIGNATURE-----
Mark Wilden
news:T4NT6.151983$eK2.36...@news4.rdc1.on.home.com...
> If I click on an object
> name to see its members and the names I see are things like "NMP", I'm
> going to start practicing voodoo in the vain hopes that the person who
made
> that object succumbs to a nasty curse because the code browser will
> definitely not show me that comment.
Just in case it's not obvious, "NMP" is a perfectly good identifier if it is
a term in the business domain.
Reinout Heeck
That is debatable,
one can think of situations during code maintanance that programmers
without domain knowledge will need to adjust the code.
If they only see 'greek' they won't be as productive.
Reinout
-------
p.koot...@remove.ieee.org
> Just in case it's not obvious, "NMP" is a perfectly good identifier if it is
> a term in the business domain.
Not My Problem?
Never Miss Payday?
Why is it an acceptable identifier in the business domain?
Ciao,
Peter K.
--
Peter J. Kootsookos Wb: www.clubi.ie/PeterK
"Here comes the future and you can't run from it,
If you've got a blacklist I want to be on it"
- 'Waiting for the great leap forwards', Billy Bragg
Mark Wilden
news:3B1FBC28...@Desk.org...
> That is debatable,
> one can think of situations during code maintanance that programmers
> without domain knowledge will need to adjust the code.
> If they only see 'greek' they won't be as productive.
First of all, the thought of someone diving into code without domain
knowledge is rather scary. Second, if it's possible to work on code without
domain knowledge (debatable), then it should be possible to work on code
with "NMP" in it without needing to know what it means. Would it help to
expand it to nextMatherizingPropersipper if the programmer doesn't know what
matherizing is or what the proper sipper does?
Mark Wilden
news:ug0dck...@remove.ieee.org...
> "Mark Wilden" <ma...@mwilden.com> writes:
>
> > Just in case it's not obvious, "NMP" is a perfectly good identifier if
it is
> > a term in the business domain.
>
> Not My Problem?
>
> Never Miss Payday?
>
> Why is it an acceptable identifier in the business domain?
That's up to the business to answer.
I worked for a telephone company, and everyone from the janitors on up knew
what a "BTN" was, so that was a legitimate identifier. Spelling it out to
billingTelephoneNumber would actually have made the code more confusing, not
less.
Michael T. Richter
Hash: SHA1
"Mark Wilden" <ma...@mwilden.com> wrote in message
news:thvavjj...@news.supernews.com...
>> If I click on an object
>> name to see its members and the names I see are things like "NMP", I'm
>> going to start practicing voodoo in the vain hopes that the person who
>> made that object succumbs to a nasty curse because the code browser will
>> definitely not show me that comment.
> Just in case it's not obvious, "NMP" is a perfectly good identifier if it
> is a term in the business domain.
Of course. Terms directly from the problem domain are *ALWAYS* acceptable
identifier names and, indeed, if appropriately used, they are the most
desired ones.
- --
Michael T. Richter
"Be seeing you."
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOx/OYbTM3QkE7U/oEQIUbACgrfGWdGa/zPa86SVsobxtM6mAmEAAni+q
7HMu5N9VMP1QMvmOL1OyBkPE
=iupz
-----END PGP SIGNATURE-----
John Clonts
who doesn't know what a UPC is. It would be ridiculous to spell it out.
Cheers,
John
<p.koot...@remove.ieee.org> wrote in message
news:ug0dck...@remove.ieee.org...
Ted Edwards
> Two words: code browser.
> If I'm on a large, complex project your solution is unworkable.
If you were working in APL, you wouldn't have the problem.
Ted
Reinout Heeck
>
> "Reinout Heeck" <re...@Desk.org> wrote in message
> news:3B1FBC28...@Desk.org...
>
> > That is debatable,
> > one can think of situations during code maintanance that programmers
> > without domain knowledge will need to adjust the code.
> > If they only see 'greek' they won't be as productive.
>
> First of all, the thought of someone diving into code without domain
> knowledge is rather scary.
That is what happens when an expert on your IDE/runtime system gets
called in...
> Second, if it's possible to work on code without
> domain knowledge (debatable), then it should be possible to work on code
> with "NMP" in it without needing to know what it means. Would it help to
> expand it to nextMatherizingPropersipper if the programmer doesn't know what
> matherizing is or what the proper sipper does?
Of course, it implies that related methods/variables may well have names
containing matherize or proper sipper.
Reinout
-------
Donal K. Fellows
> Michael T. Richter wrote:
>> If I'm on a large, complex project your solution is unworkable.
> If you were working in APL, you wouldn't have the problem.
Why? Because you wouldn't have a large, complex project but just a small
project rendered complex by the language? >:^)
Donal (now let's see how many irate messages from the humor-impaired I
receive over the next six months...)
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
p.koot...@remove.ieee.org
> I worked for a telephone company, and everyone from the janitors on up knew
> what a "BTN" was, so that was a legitimate identifier. Spelling it out to
> billingTelephoneNumber would actually have made the code more confusing, not
> less.
I suppose I'm thinking of a particular company that uses 4LAs (they
started with 3LAs and ran out) for EVERYTHING. No-one in the business
domain could keep track of all of them; certainly the SW guys couldn't
either.
Steve Simmons
> I have folks here in comp.lang.fortran who claim hard that they
>
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
Same here.
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
Short response: you can make bad variable names of any length.
Partially disagree. Selective use of case mixing is useful; for
example `SecondLevelPointer' is a helluva lot more readable than
`secondlevelpointer'. However, if the var names are heavily
abbreviated then case mixing doesn't help much: `ScndLvlPtr'.
More can be achieved if underscores are allowed, which makes
`Second_Level_Pointer' extremely readable (tho hard to type).
IMHO the typing issue has caused more bad short var names
than anything else. I believe that modern programmers editors
can do name completion, but I'm still a vi bigot...
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
Yes, and IMHO this argues for names less than 30 characters. It's
nice to know at a glance what a variable does, which seems to argue
for names like `Pointer_To_Top_of_Disk_Read_Queue'. However,
if code is at all modularized the context of what you're working
on is enough to make `Read_Queue' an equally good name.
--
"I used to really hate Ameritech, but now I have Verizon."
--unknown person at local technical meeting (SEMiSLUG)
Mark Wilden
> >
> > First of all, the thought of someone diving into code without domain
> > knowledge is rather scary.
>
> That is what happens when an expert on your IDE/runtime system gets
> called in...
And he starts changing code without knowing the domain? In that case, since
he's not working at a particularly semantically high level, he probably does
not need to know what NMP means. (I've never worked with someone who didn't
know the domain.)
> > Second, if it's possible to work on code without
> > domain knowledge (debatable), then it should be possible to work on code
> > with "NMP" in it without needing to know what it means. Would it help to
> > expand it to nextMatherizingPropersipper if the programmer doesn't know
what
> > matherizing is or what the proper sipper does?
>
> Of course, it implies that related methods/variables may well have names
> containing matherize or proper sipper.
Anyone who programmed on the basis of such a correlation without really
knowing what he's talking about is going to have trouble, I think.
Ted Edwards
> Donal (now let's see how many irate messages from the humor-impaired I
> receive over the next six months...)
How about dropping comp.lang.apl of your list of cross-postings. The
only thing I've got out of this thread is a good understanding of why
there is so *much* bad code out there.
'course what would I know, I'm just a beginner. Only been programming
since the mid 50's.
Ted
Jim Lucas
> Ted Edwards wrote:
> > Michael T. Richter wrote:
> >> If I'm on a large, complex project your solution is unworkable.
> > If you were working in APL, you wouldn't have the problem.
>
> Why? Because you wouldn't have a large, complex project but
> just a small project rendered complex by the language? >:^)
Or a "large, complex" project rendered small by the language?
(Of course, it depends on the nature of both the project and the language.)
> Donal (now let's see how many irate messages from the
> humor-impaired I receive over the next six months...)
Humor-impaired, that's me. Is there a free-software version? Maybe I would
understand it better if I could study the source of "humor".
8^o /Jim
Jim Lucas
> Mark Wilden wrote:
> >
> > ...if it's possible to work on code without domain knowledge
> > (debatable), then it should be possible to work on code
> > with "NMP" in it without needing to know what it means.
> > Would it help to expand it to nextMatherizingPropersipper
> > if the programmer doesn't know what matherizing
> > is or what the proper sipper does?
>
> Of course, it implies that related methods/variables may
> well have names containing matherize or proper sipper.
"Of course,"?? But then, "may well have" is hardly the same thing as "will",
so perhaps I should lower my eyebrows.
/Jim
Dave Harris
> > |On the other hand, there is a lot of redundancy in that repetition of
> > |"negativeMachinePrecision".
>
> I guess I don't understand your use of the term "redundancy." What is
> the difference between repeating a variable named "a" or a variable
> named "negativeMachinePrecision?"
I'm not sure what "a" means here or how it relates to the example.
Repeating "result" involves less redundancy - in this context - than
repeating "negativeMachinePrecision" because the latter has more unneeded
information. "Result" is a clearer name because it provides exactly the
information we need (given that we know from the context which result we
are dealing with).
> > Ideally we would factor out the common part
> > |somehow. I don't mean abbreviations like "ngtvMchnPrcsn" so much
> > |as names like "expectedResultLimit". That the result is a
> > negativeMachinePrecision ought to be obvious from the context. If
> > it is not obvious, how can we make it obvious?
>
> Sorry, -- your point is completely vague and lost on me!
Well, the code would probably be in a method called
"testNegativeMachinePrecision". This method forms part of the context. We
know that anything called "result" is going to be the result of the test
and therefore will be the negativeMachinePrecision. We don't need to
repeat the longer string each time.
The class name also provides context. For example, I would not expect to
see a method like "customerName" in a class called "Customer". It could be
called "name" instead. It'd be obvious - from the context - whose name it
was.
By "how can we make it obvious?" I mean to suggest adding new classes or
methods, or perhaps even language constructs. For example, someone just
gave code like:
temporary_bean_index := temporary_bean_index + 1;
This would be clearer if the language added a new operator like:
temporary_bean_index +:= 1;
or even:
++temporary_bean_index;
The increment might be factored out altogether if the language has block
closures, so we could write (in Smalltalk):
bean_counter keysAndValuesDo: [:key :value| ... ]
or (in C++) use std::transform().
> > |Long names are sometimes a code smell that suggests we are not
> > |getting enough milage out of the context.
>
> I have not experienced this. I am currently refactoring some code
> where the original developer used names like "tmp" and "oc." If
> there is such a thing as code smell -- it is certainly more prevalent
> in the use of these types of names where the original developer
> understood the context, but failed to communicate it in the code.
When I wrote above, "I don't mean abbreviations like...", that is the kind
of thing I had in mind. So we are in agreement here.
> > |Maybe it means we are trying to do too much in one object.
>
> Once again -- I don't get this point -- in the context of this
> discussion! How is the choice of a name related to how much work or
> code is implemented in one object?
The more methods an object has, the longer their names need to be to be
unambiguous.
For example, if a class has methods "deliveryAddressLine1",
"billingAddressLine1" etc, then there is scope for factoring out an
Address class with method "line1", and giving the original class methods
"deliveryAddress", "billingAddress".
> > |For this reason I think well-written OO code has less trouble
> > |with long names than, say, C.
>
> I don't quite agree with this conclusion. I don't think it is valuable
> to try an eliminate the number of characters that one types for the name
> of a variable. The most important quality one can have in their code is
> expressiveness and clarity.
I agree with that last sentence, but I think clarity is helped by avoiding
redundancy. It is a subtler issue than "number of characters".
If we see declarations like:
string addressLine1;
string addressLine2;
string addressLine3;
string addressLine4;
then that is crying out to be refactored more like:
struct address {
string line[4];
};
The second version has less redundancy. That it also has fewer characters
is a bonus. It will usually be more reusable and more expressive. We can
print out the address lines with a loop instead of 4 separate statements.
We can make it easy to change the number of lines.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Lex Spoon
> : languages in this cross-posted article allow many characters in a name, and
> : so such a commenting style is superfluous, and thus discouraged.
>
> decl temporary_bean_index: integer := 0;
> while temporary_bean_index < 100 do
> bean_counter[temporary_bean_index] :=
> bean_counter[temporary_bean_index] + beans_counted(temporary_bean_index);
> temporary_bean_index := temporary_bean_index + 1;
> end;
>
> vs. the obvious.
>
> So your rule is not so universal?
>
I agree that just using "i" would be better. In fact, it's the kind
of case that comes to my mind when this issue comes up. Sometimes
it's easier to read the code than to study a variable on its own; loop
indeces are a likely candidate.
Note: it's not true when you have multiple nested loops, however -- i,
j, and k are inferior to fooIndex, barIndex, and zapIndex. The longer
the code in scope, the longer the names should be. :) But to solve
that problem, you can frequently move individual loops into their own
subroutines; every language will let you move out the inner loops, and
many will let you move out the outer loops.
Furthermore, even when open-coded this loop can be improved. First,
most languages have a FOR loop if your bounds are fixed, as they are
in this case. Second, quite a few languages have a "collect" or "map"
operation that can be used to *really* shorten this loop. For example:
beansCounted :=
(0 to: 99) collect: [ :beanIndex |
self beansCounted: beanIndex ]
I know it looks like cheating, but actually I seem to *very* rarely
need to open code an array manipulation when writing Smalltalk.
-Lex
Carl Gay
> The class name also provides context. For example, I would not expect to
> see a method like "customerName" in a class called "Customer". It could be
> called "name" instead. It'd be obvious - from the context - whose name it
> was.
I just want to point out that at least two of the groups to which this thread is cross-posted don't use classes to define namespaces. Method names aren't IN classes, they're in modules or packages. That doesn't negate your point, of course.
I have found (in Java) one major drawback to this shortening of names because of all the tiny little class namespaces. It becomes quite difficult to find all callers of a given method if there are several methods called "name" in several different classes. I also frequently want to search for all occurrences of some string in my sources. (e.g., to rename something) If I can search for "customerName" rather than just "name" (or, more commonly in Java, "getName") it will greatly reduce the number of false matches. Although there may be IDEs that will reduce this problem (?), I still can't assume everyone will have access to the same IDE I have.
John Sullivan
Spoon <l...@cc.gatech.edu>
>> : However, many of the
>> : languages in this cross-posted article allow many characters in a name, and
>> : so such a commenting style is superfluous, and thus discouraged.
>>
>> decl temporary_bean_index: integer := 0;
>> while temporary_bean_index < 100 do
>> bean_counter[temporary_bean_index] :=
>> bean_counter[temporary_bean_index] + beans_counted(temporary_bean_index);
>> temporary_bean_index := temporary_bean_index + 1;
>> end;
>>
>> vs. the obvious.
>>
>> So your rule is not so universal?
>>
>
>I agree that just using "i" would be better. In fact, it's the kind
>of case that comes to my mind when this issue comes up. Sometimes
>it's easier to read the code than to study a variable on its own; loop
>indeces are a likely candidate.
>
>Note: it's not true when you have multiple nested loops, however -- i,
>j, and k are inferior to fooIndex, barIndex, and zapIndex. The longer
>the code in scope, the longer the names should be. :) But to solve
>that problem, you can frequently move individual loops into their own
>subroutines; every language will let you move out the inner loops, and
>many will let you move out the outer loops.
>
cross-posted is for a language that processes arrays all in one go, and
for which loops are inappropriate except for i/o.
>
>Furthermore, even when open-coded this loop can be improved. First,
>most languages have a FOR loop if your bounds are fixed, as they are
>in this case. Second, quite a few languages have a "collect" or "map"
>operation that can be used to *really* shorten this loop. For example:
>
> beansCounted :=
> (0 to: 99) collect: [ :beanIndex |
> self beansCounted: beanIndex ]
>
>
>
>I know it looks like cheating, but actually I seem to *very* rarely
>need to open code an array manipulation when writing Smalltalk.
>
>
>
>-Lex
>
--
John Sullivan Remove the dots in yDdraigGoch for my real address.
-------------
Virtuoso: someone who plays pieces of music of little artistic merit
faster and louder than anyone else.
Ken Travers
"Steve Wart" <sw...@deadspam.com> wrote in message
news:arGP6.299770$166.6...@news1.rdc1.bc.home.com...
> How about spaces in names of identifiers is doom?
>
> Holy smokes. I knew I stopped at FORTRAN 77 for a reason :)
>
> Cheers,
> Steve
I'm not normally one to complain, but I have to say this thread has become
very difficult to read (from an APL viewpoint) because most of the items DO
NOT RELATE TO APL.
I have limited time (and I read slowly). Does anyone else share my concern?
Ken Travers.
Peter Pichler
>
>I'm not normally one to complain, but I have to say this thread has become
>very difficult to read (from an APL viewpoint) because most of the items DO
>NOT RELATE TO APL.
>
>I have limited time (and I read slowly). Does anyone else share my
concern?
Yes. Here on comp.lang.c.
--
Peter Pichler (Increment my "From:" address if your email bounces.)
This message is not solicitation for contact via email or phone.
Steve Wart
When I studied APL I recall using identifiers like A and B. Has this
situation improved, or are APL programs so short and readable that
meaningful identifiers are not an issue?
I remember at the time it was a dead cool language, and I could do reporting
things with it that seemed to horrify the FORTRAN programmers of the world,
but that was on a mainframe 20 years ago.
APL always seemed to me to be the ideal macro language for spreadsheets,
although nobody else seems to have picked up on this :-) I realize that
this is likely a FAQ, but are there free or open-source APL implementations
available? (Although I realize it will never be the same without an AJ510
keyboard)
Also, I seem to recall an interesting relationship between APL and Lisp, but
I don't recall exactly what it is. I suppose it has something to do with
functional programming...wasn't APL originally a specification language for
Lisp programs?
[p.s. I've removed comp.lang.c at the risk of annoying the rest of the
non-APLers this time...hey, how come comp.lang.fortran is not on the
distribution list? I suspect this a trick by fortran programmers to make the
rest of us unproductive, since that was who started the thread in the first
place!]
Cheers,
Steve
Eric Moss
> "Reinout Heeck" <re...@Desk.org> wrote in message
> news:3B1FBC28...@Desk.org...
>
> > That is debatable,
> > one can think of situations during code maintanance that programmers
> > without domain knowledge will need to adjust the code.
> > If they only see 'greek' they won't be as productive.
My meager living is made by doing just that--cleaning up other people's
uncommented code, the point of which was forgotten long before. It's a
nightmare, and a few hints (that admittedly cost the original coder some
time) would make my job (and so many others') easier. They seem obvious, but
maybe that's why they keep getting forgotten. Or maybe there's a false
economy attitude that comments don't get the work done. :( Anyway...
[1] Pull as much generic code as possible into a separate function where
variables like a, b and c are reasonable. Keep the domain-specific names in
the higher-level code. A trivial example is no write a generic sorting
routine rather than inlining the code. This approach seems easier to do in
languages like lisp, but in any language, try to go as far as possible in
this direction. There may even be a design patterns tie-in to make this
sound important enough to try. :)
[2] Maintain locality of explanations: Abbreviate only as far as you can
without having to move descriptions into another file, or worse, into
another subproject. The closer together the symbol and its definition, the
easier it is to see that an NMP (or whatever) is actually an
N<etc>M<etc>P<etc>.
[3] Sophisticated IDEs can help tremendously, as long as they display the
information you (might) need without the programmer having to switch mental
contexts to go hunt for it. On the other hand, as someone stuck with a
lesser editor still needs to be able to do the work, it's still preferable
(from my viewpoint) to have the code and explanations close enough for a
plain text viewer to be usable.
The first two points are synergistic, in that the more one separates the
generic from the specific, the more the generic code can be put out of sight
in some library, and domain-specific code with the special names can be kept
close together.
It all boils down (for me) to minimizing how much time is spent changing
mental gears looking for explanations, minimizing time spent on separating
the domain-specific from the generic, and therefore maximizing the time
spent on understanding the intent of the code.
> First of all, the thought of someone diving into code without domain
> knowledge is rather scary. Second, if it's possible to work on code
without
> domain knowledge (debatable), then it should be possible to work on code
> with "NMP" in it without needing to know what it means. Would it help to
> expand it to nextMatherizingPropersipper if the programmer doesn't know
what
> matherizing is or what the proper sipper does?
Not much (you knew that), unless there's a place to find the long name
explained. Even google can't help much with NMP. :) Type declarations in the
top-level code can help here, I think:
NextMatherizingPropersipper* nmp = nil;
if (nmp==nil) {...}
for example.
I hope this adds to the conversation...
Eric
Mark Wilden
news:9g62od$2ja$1...@iac5.navix.net...
>
> > Would it help to
> > expand it to nextMatherizingPropersipper if the programmer doesn't know
> what
> > matherizing is or what the proper sipper does?
>
> Not much (you knew that), unless there's a place to find the long name
> explained. Even google can't help much with NMP. :)
Actually, search engines are very good at finding weird abbreviations and
acronyms.
> Type declarations in the
> top-level code can help here, I think:
>
> NextMatherizingPropersipper* nmp = nil;
>
> if (nmp==nil) {...}
Again, if you don't know what those terms mean, they might as well stay as
(unique) abbreviations. Especially if everyone you talk to in the business
actually uses a term like NMP all the time.
> I hope this adds to the conversation...
I usually only reply to parts I disagree with or feel I can elaborate on. I
don't reply to parts I agree with, which is why I didn't reply to most of
your post. :)