Long names are doom ?
00001111
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 will die claiming 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
Chris Smith
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Yes, I do occasionally use very long identifiers. Normally, I do so when I
am using a lot of identifiers according to a set naming convention. For
example, I might, in a Swing GUI application, declare an Action subclass
called:
viewPreferencesGeneralOptionsAction
That's 35 characters. If that's really my menu structure (that is, view |
prefs | general | options) then I really want to use that variable name.
This is not to say that I very frequently use such names, but when I need to
for consistency, I'd really hate for the language to stand in my way.
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
Mostly true, but I disagree with the absolute statement.
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
Definitely true.
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
Definitely true.
For those reasons, I don't agree with regularly using long variable names
unless, like in the example above, they make intuitive sense and there's
some systematic reason for that name choice.
Chris Smith
Larry Elmore
I regularly use names longer than 31 characters, but it's in large part
due to naming conventions in force at work (every function name must
start with the name of the protocol being implemented, for example,
"etsiBssmapLe3...") which eats up characters. Those rules stem from the
limitations of the language, which is a proprietary extension of C.
Also, I use the names provided by the specs without any attempts at
abbreviations because short, abbreviated names are a false economy since
whatever time is saved in typing will be be paid back tenfold later on
when doing maintenance. Being completely unambiguous and avoiding any
possible confusions makes future modifications _so_ much easier than
trying to figure out some of the damnably cryptic abbreviations other
programmers have used at work -- it's not easier reading if you have to
read _5_ different source files to figure out which _1_ corresponds to a
given parameter in a spec!
I must say that _most_ names I use are <= 31 characters, though.
Larry
Patricia Shanahan
00001111 wrote:
...
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
...
That is the most important single point, and the reason why long
identifiers are a good thing to have available.
Abbreviations in identifiers make them less memorable. For a given
concept, there is the full name and possibly several ways of
abbreviating it, and anyone using it has to remember which to use. I try
to avoid them in public names, including class names.
Also, a consistent naming system makes names more memorable.
Sometimes, very rarely, a consistent naming scheme can lead to a
situation in which limiting the name to e.g. 31 characters would require
it to either break its naming convention or have some components
abbreviated.
For example, take a look at the constant names in
javax.accessibility.AccessibleContext. Names such as
"ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
either abbreviating or not using a consistent scheme, but doing so would
make them harder to remember. In Fortran I suppose it would be called
something like ACCTABCOLDESCCHNGE.
Patricia
Roedy Green
quoted :
>> - "it degrades the legibility of a program to use identifiers that
>> can't be easily remembered...."
>...
>
>That is the most important single point, and the reason why long
>identifiers are a good thing to have available.
The other place long names can be useful is in mechanically generated
code.
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/gloss.html or http://209.153.246.39/gloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963.
Almost ready to take on new work.
Jan Schaumann
> "00001111" <0000...@my-deja.net> wrote ...
> > Anybody use variables/names longer than 31 character
> > and finds it really useful ?
>
> Yes, I do occasionally use very long identifiers. Normally, I do so when I
> am using a lot of identifiers according to a set naming convention. For
> example, I might, in a Swing GUI application, declare an Action subclass
> called:
>
> viewPreferencesGeneralOptionsAction
>
> That's 35 characters. If that's really my menu structure (that is, view |
> prefs | general | options) then I really want to use that variable name.
viewPrefsGenOptAction - that's 21, and just as readable.
-Jan
--
Jan Schaumann
http://www.netmeister.org
tmo...@acm.org
> and finds it really useful ?
> Then please respond why, where, when.
When I'm in too big a hurry to do it right?
Coming up with good names is neither quick nor easy. Sometimes it's
better to be verbose and clean it up later, than to be cryptic and
try to clean it up later.
Steve Bellenot
While 31 is arbitrary and obviously ``wrong'' for not being 0, 1 or
infinity, I must agree that identifiers longer that most Russian novels
are worst. [Especially to those of us who have worked with people who
indent 2 spaces at a time, use a 132 column editor and consider the
whitespace as a goal to fill.] That is there must be some number n
where the pain of seeing identifiers of length > n is worst than the
pain of having to make all identifers have length <= n. It is more
likely that the answer is 42, but it could be 31.
--
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu
+1.850.644.7189 (4053fax)
Jim Monty
> 00001111 wrote:
> ...
> > - "it degrades the legibility of a program to use identifiers that
> > can't be easily remembered...."
> ...
>
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
>
> Abbreviations in identifiers make them less memorable. For a given
> concept, there is the full name and possibly several ways of
> abbreviating it, and anyone using it has to remember which to use. I try
> to avoid them in public names, including class names.
Would you be "less memorable" if you were
Patricia_Shanahan@Association_of_Computing_Machinery.Organization
instead of simply
Easily ninety percent of all Web users have no idea what any of
the abbreviations http, www, com, org, etc. stand for. But does
that make it harder for them to remember the URL www.mtv.com?
Imagine a typical URL spelled out in its entirety. It would be
absurdly long and unwieldy!
We use abbreviations for various reasons, not the least of which
is as a mnemonic aid. This is certainly true of identifiers in
computer programming languages.
> Also, a consistent naming system makes names more memorable.
I don't think anyone would disagree with that. But given two
consistent naming systems (or two inconsistent naming (non-)systems),
which one is to be preferred: the one that allows long names or
the one that does not?
There's no One Answer for every language, culture, compiler, company,
and circumstance. This topic is mostly fodder for religious wars.
> Sometimes, very rarely, a consistent naming scheme can lead to a
> situation in which limiting the name to e.g. 31 characters would require
> it to either break its naming convention or have some components
> abbreviated.
So abbreviate consistently. And don't forget to use acronyms, too
("EOF", "NaN", etc.).
> For example, take a look at the constant names in
> javax.accessibility.AccessibleContext. Names such as
> "ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
> either abbreviating or not using a consistent scheme, but doing so would
> make them harder to remember. In Fortran I suppose it would be called
> something like ACCTABCOLDESCCHNGE.
Or ACCESS_TBL_COL_DESC_CHGD (24 characters). This is no more
difficult to remember than your 43-character, spelled-out version.
Indeed, I have seen each of these same four abbreviations used many
times before. They're pretty standard.
--
Jim Monty
mo...@primenet.com
Tempe, Arizona USA
Patrick Logan
"00001111" <0000...@my-deja.net> wrote
in message news:3B0DBD4A...@my-deja.net...
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
>
> Then please respond why, where, when.
(1) Source code generators can easily generate new names when
they do not have to consider name length.
[All kinds of limits can be reached more easily by automatic
generator tools. This used to be very common. Newer compilers
have taken this into consideration based on experience.]
(2) Editors with completion make long names tolerable. Languages
without name space mechanisms make long names necessary.
Readable code includes names longer than 31 character sometimes
when programmers combine longer, unabbreviated names. But
hopefully not often.
--
Patrick Logan
mailto:patric...@home.com
Jon Skeet
> Easily ninety percent of all Web users have no idea what any of
> the abbreviations http, www, com, org, etc. stand for. But does
> that make it harder for them to remember the URL www.mtv.com?
> Imagine a typical URL spelled out in its entirety. It would be
> absurdly long and unwieldy!
>
> We use abbreviations for various reasons, not the least of which
> is as a mnemonic aid. This is certainly true of identifiers in
> computer programming languages.
Yes, we use abbreviations and acronyms for *common* things - but given a
general long variable name, in many cases there won't be a "standard"
abbreviation, so the author has to check each time or until they
remember - and each poor maintenance programmer has to learn the same
set of abbreviations!
Abbreviations are fine when they're unambiguous and easily remembered,
but not when there could be a dozen ways of abbreviating a long name.
--
Jon Skeet - sk...@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time
Florian Weimer
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Constants for Unicode characters?
GREEK_CAPITAL_LETTER_ALPHA_WITH_DASIA_AND_PERISPOMENI_AND_PROSGEGRAMMENI
ARABIC_LIGATURE_UIGHUR_KIRGHIZ_YEH_WITH_HAMZA_ABOVE_WITH_ALEF_MAKSURA_ISOLATED_FORM
SCNR.
Peter Fitzgibbons
> likely that the answer is 42, but it could be 31.
As in the answer to life.
6 x 9
(13)
Charles Demas
No, it isn't. e.g. the "Gen" could have meant "Generate",
and viewPrefsGenOptAction and viewPrefGenOptAction could
easily get typed for the same variable. Using the full words
prevents differing abreviations being used by different authors.
Chuck Demas
--
Eat Healthy | _ _ | Nothing would be done at all,
Stay Fit | @ @ | If a man waited to do it so well,
Die Anyway | v | That no one could find fault with it.
de...@tiac.net | \___/ | http://www.tiac.net/users/demas
Marin David Condic
I've used, and seen used, identifiers longer than 31 characters. If done
judiciously and with a proper sense of purpose, this can be a big aid in
understanding a program. It may avoid cryptic abbreviations and possibly
help you sort out variables v constants v procedures v types and so forth.
As with anything, it can be badly overdone. (To index an array, what's wrong
with "for X in Some_Array'Range"? Would someone find it superior to say "for
An_Index_For_The_Array_Called_Some_Array in Some_Array'Range"?)
One may choose not to use names longer than 6 characters. That's their
judgement call. However, I see no reason to put this sort of restriction
into the language design. Not in the days of megabytes of memory and
gigabytes of disk space.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"00001111" <0000...@my-deja.net> wrote in message
news:3B0DBD4A...@my-deja.net...
>
Marin David Condic
length, then 42 is a better number than 31.
One can argue all day about programming style. Hemmingway had a very
different writing style when compared to James Joyce. (And we can compare
the both of them to Douglas Adams if you like.:-) Were both good writers?
While the analogy doesn't hold across all cases, consider that it is
possible to write good programs with short identifiers and with long
identifiers. Which to use and when may be a matter of the project at hand
and the style chosen for the project. (Short shell scripts probably don't
need extensive naming conventions but multi-million SLOC rocket control
systems will probably benefit if all identifiers are not restricted to 6
characters.)
I think that engineers have to make some stylistic choices when undertaking
a particular project, and those choices will have tradeoffs. It would be
wrong for a language to force you to *never* use identifiers longer than 6
(or 31) characters. Computers are big. If you're going to have an arbitrary
limitation for ease of implementation, why not make it 256? Nobody is likely
to complain that they can't write code because the identifiers they use need
to be bigger than that.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Steve Bellenot" <bell...@math.fsu.edu> wrote in message
news:9ekrc2$hk0$1...@news.fsu.edu...
Everett M. Greene
>
> 00001111 wrote:
> ....
> > - "it degrades the legibility of a program to use identifiers that
> > can't be easily remembered...."
>
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
>
> Abbreviations in identifiers make them less memorable. For a given
> concept, there is the full name and possibly several ways of
> abbreviating it, and anyone using it has to remember which to use. I try
> to avoid them in public names, including class names.
>
> Also, a consistent naming system makes names more memorable.
>
> Sometimes, very rarely, a consistent naming scheme can lead to a
> situation in which limiting the name to e.g. 31 characters would require
> it to either break its naming convention or have some components
> abbreviated.
>
> For example, take a look at the constant names in
> javax.accessibility.AccessibleContext. Names such as
> "ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
> either abbreviating or not using a consistent scheme, but doing so would
> make them harder to remember. In Fortran I suppose it would be called
> something like ACCTABCOLDESCCHNGE.
Not at least in earlier versions of ANSI Fortran (6 chars).
I was once involved with a (Government) project which was
going to use coded identifiers for all the programming
components and do it in ANSI Fortran (77?)! I was still
contemplating how that was going to be done when the
project was cancelled for lack of need.
tmo...@acm.org
> I have folks here in comp.lang.fortran who will die claiming that
There may actually exist data on this normally faith-based question:
Section 3.3, "Naming Conventions", in "Ada Quality and Style -
Guidelines for Professional Programmers" says "... you can further
improve comprehension if your variable names are not excessively long."
and references p.7 of Schneiderman, B. 1986 "Empirical Studies of
Programmers: The Territory, Paths and Destinations" in "Empirical
Studies of Programmers" ed. E. Soloway and S. Iyengar.
Marin David Condic
usually personal preference backed up with "evidence" arrived at through
rectal extraction.
Perhaps a controlled study could be performed? Take a single module of
reasonable complexity (a hundred lines or so) and code it with long and
short names. Insert a bug. Determine how long it takes a few dozen
programmers to find and fix the bug. Similarly, code a system of higher
complexity - say 10 packages of 5 subprograms each (find one already out
there?) and code it both ways. (Auto-translate long names to short names).
Insert a bug. See how long it takes the programmers to find and fix it.
That sort of test would not be impossible to construct and could be done
relatively easily in a controlled environment. If well constructed, it ought
to settle the debate and suggest what we ought to be doing when coding
things of different sizes. At least with respect to evolving systems. Throw
away code (write only memory?) may be faster to develop with only single
character identifiers and who cares about understanding it?
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
<tmo...@acm.org> wrote in message
news:EJwP6.33931$%i7.27...@news1.rdc1.sfba.home.com...
Roedy Green
<marin.condic...@pacemicro.com> wrote or quoted :
>If you're going to have an arbitrary and capricious limit on identifier
>length, then 42 is a better number than 31.
You could ask it this way. Who is better able to judge whether a given
long variable is justified, somebody versed in the project or somebody
who has never seen it?
This is a matter of style, and such a thing MIGHT be enforceable on a
PROJECT basis.
I would like it if there were lint-like tools that guarded the
repository. They would beautify code to project standards, and
enforce restrictions decided on a per-project basis.
They would enforce the naming rules, see Coding Conventions in the
Java glossary.
You might even demand that each element of a variable name live in a
dictionary. What drives me nuts is maintaining somebody else's code
who can't spell.
I could imagine that a SCID would have a project dictionary with
special terminology carefully defined. Coming cold into a project
learning the undocumented vocabulary is the hardest thing. All words
used in variable names would have to be defined if the standard Oxford
definition did not suffice.
We need to evolve computer languages more toward communication: human
<=> human and machine => human, rather than just human => machine.
One example would be avoiding nested scope to resolve ambiguity.
Computers have no problem with it, but in many cases it befuddles
humans.
Larry Hazel
I worked on a FORTRAN project once (F4J pilot trainer). All variable names were
in a data dictionary. The compile script ran the code through a parser and
looked all variable names up in the data dictionary. If you misspelled a
variable or made up a new one, the program wouldn't compile. To get a new
variable, you had to submit it with definition and justification to the
maintainer of the data dictionary. It kept the error rate down a bunch.
The project was converted to Ada as a company funded R&D project in 1985. The
conversion went very smoothly.
Larry
Jon Skeet
Note that data which was accurate in 1986 may not be applicable now -
screen space isn't at quite such a premium now, and syntax highlighting
(maybe it was available then; I don't know) helps readability too.
robin
> > "00001111" <0000...@my-deja.net> wrote ...
> >
> > am using a lot of identifiers according to a set naming convention. For
> > example, I might, in a Swing GUI application, declare an Action subclass
> > called:
> >
> > viewPreferencesGeneralOptionsAction
> >
> > That's 35 characters. If that's really my menu structure (that is, view |
> > prefs | general | options) then I really want to use that variable name.
>
> viewPrefsGenOptAction - that's 21, and just as readable.
er -- unreadable.
view_Prefs_Gen_Opt_Action is better style.
robin
>
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
>
> Abbreviations in identifiers make them less memorable. For a given
> concept, there is the full name and possibly several ways of
> abbreviating it, and anyone using it has to remember which to use. I try
> to avoid them in public names, including class names.
>
> Also, a consistent naming system makes names more memorable.
>
> Sometimes, very rarely, a consistent naming scheme can lead to a
> situation in which limiting the name to e.g. 31 characters would require
> it to either break its naming convention or have some components
> abbreviated.
>
> For example, take a look at the constant names in
> javax.accessibility.AccessibleContext. Names such as
> "ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
> either abbreviating or not using a consistent scheme, but doing so would
> make them harder to remember. In Fortran I suppose it would be called
> something like ACCTABCOLDESCCHNGE.
or ACC_TAB_COL_DESC_CHNGE
> Patricia
Jonas Lindström
news:BFDP6.20482$hV3....@newsfeeds.bigpond.com...
That depends on which language you are using.
/Jonas L
Larry Kilgallen
> Would you be "less memorable" if you were
>
> Patricia_Shanahan@Association_of_Computing_Machinery.Organization
>
> instead of simply
>
> pa...@acm.org?
"Shanahan" is not particularly meaningful to me, so whether "pats"
is a "Shanahan" or a "Shannon" or a "Smith" does not particularly
help me understand the meaning of a message. Identifiers in programs
are (should be) different, and which of many possible original words
was reduced to make a particular abbreviation is important.
I can see how people might feel abbreviations are important in tiny
programs, but when you get up beyond 200,000 source lines of code
(where one begins to choose Ada) understanding the name of a particular
subprogram can be a bit tougher.
> Easily ninety percent of all Web users have no idea what any of
> the abbreviations http, www, com, org, etc. stand for. But does
> that make it harder for them to remember the URL www.mtv.com?
> Imagine a typical URL spelled out in its entirety. It would be
> absurdly long and unwieldy!
A guiding principle of Ada is that programs are written for the
convenience of the reader rather than the author. Thus typing
effort is not important compared to clarity.
Larry Kilgallen
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Absolutely.
> Then please respond why, where, when.
In an Ada package automatically generated from ASN.1 specifications.
The long names contain the exact derivation of each identifier,
based on combining the names used for the ASN.1 modules from which
they are derived and their names within those modules.
> I have folks here in comp.lang.fortran who will die claiming 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...."
Yes, the identifiers are hard to read, but that is better than having
the information missing. Recently I had the opportunity to read
some code in C that regularly exceeds a length of 31 characters. I
tried (before I understood my compiler for C, not my native language)
to come up with shorter names for these identifiers, and found that
my human-shortened names were _never_ as meaningful as the original
for someone who understands the problem domain.
> 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.
Those who implement Ada compilers are required to support at least
200 characters. I made the mistake of inadvertently going over that
limit on a more permissive compiler, only to redo the generator when
I tried to use the result on a less permissive compiler. You would
be well advised to require at least the capability for a warning at
whatever the minimum number of siginificant characters is to be.
Larry Kilgallen
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic...@pacemicro.com> wrote or quoted :
>
>>If you're going to have an arbitrary and capricious limit on identifier
>>length, then 42 is a better number than 31.
>
> You could ask it this way. Who is better able to judge whether a given
> long variable is justified, somebody versed in the project or somebody
> who has never seen it?
>
> This is a matter of style, and such a thing MIGHT be enforceable on a
> PROJECT basis.
>
> I would like it if there were lint-like tools that guarded the
> repository. They would beautify code to project standards, and
> enforce restrictions decided on a per-project basis.
I would guess it would be a very simple ASIS program to detect
unacceptable (for the project) identifiers, on the basis of
length or some other standards. That one ASIS program should
be quite portable between different brands of Ada compilers.
Tom Spilman
by the language designers. Limiting maximum length for identifiers for
reasons other than technical limits or ease of implementation is naive and
forces an unnecessary constraint for legitimate uses. Tom
"00001111" <0000...@my-deja.net> wrote in message
news:3B0DBD4A...@my-deja.net...
>
> 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 will die claiming 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
>
>
AG
news:3B0DD011...@acm.org...
>
>
> 00001111 wrote:
> ...
> > - "it degrades the legibility of a program to use identifiers that
> > can't be easily remembered...."
>
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
>
> Abbreviations in identifiers make them less memorable.
One could argue though, that longer identifiers create more chances
for mistakes in themselves (just by virtue of been longer) than short
ones. Some other poster mentioned maintaining code written by
people who can't spell but there is also the matter of different spellings.
I once saw some code which used (in the same namespace) identifiers
PassThruID and PassThroughIDs. They were apparently introduced
by separate programmers over time and worked fine until someone
confused them. Took ages to sort it out. So, while those two aren't
even at 31 char limit, one could argue that 6 char limit would have
precluded that sort of error :)
Gary Scott
language committee. Fortran does not specify the MAXIMUM length of
identifiers, it specifies the MINIMUM length that must be supported by a
compiler. Some compilers support "infinite" length names. Some
compiler vendors were also against extremely long names because it would
have severely broken their existing compiler (complete redesign
required).
The minimum length of 31 was likely chosen for C compatibility. There
unfortunately has always been a war between factions that want to make
Fortran more "general purpose" and those that want to retain (hold back
(er limit compiler complexity)) its niche status in the numerical
computation arena. Mathematical algorithms with extremely long names
used as variables are usually less clear. Math is highly
symbolic/mnemonic oriented. Most scientists and engineers (i.e.
"non-professional"-programmers) are extremely comfortable with
abbreviations/symbols/mnemonics. I personally like the shorter limit,
but I WOULD like to see some sort of a name ALIAS facility for externals
to aid interfacing with other languages (that decorate names, or with
otherwise different naming rules, or that allow characters within a name
that Fortran does not allow, etc).
--
Gary Scott
mailto:sco...@flash.net
mailto:webm...@fortranlib.com
http://www.fortranlib.com
Support the GNU Fortran G95 Project: http://g95.sourceforge.net
Shankar Unni
> I once saw some code which used (in the same namespace) identifiers
> PassThruID and PassThroughIDs. They were apparently introduced
> by separate programmers over time and worked fine until someone
> confused them. Took ages to sort it out. So, while those two aren't
> even at 31 char limit, one could argue that 6 char limit would have
> precluded that sort of error :)
Really? Would it have been somehow been a lot clearer, and harder to
confuse the two, if they had been, say, "PTID" and "PTIDS"? I'd think
the opposite, actually..
You're right in that infinitely long names don't help beyond a certain
point, but 6 chars is ridiculous. Forcing ultra-short names has the
effect of people using an acronym soup for variable names, and "ABCXQZ"
is pretty easy to confuse with "ABCQXZ".
Here's an *actual* example of code I saw posted in another newsgroup
(names erased to protect the guilty - or in this case, the innocent!).
And these are 12-char names - think how much more readable this would
have been with 6-char names:
> double sicjpcisj=*scratchptr;
> double sicjncisj=*(scratchptr+1);
> double cicjpsisj=*(scratchptr+2);
> double cicjnsisj=*(scratchptr+3);
> double qcksicjpcisj,qcksicjncisj;
> double qsksicjpcisj,qsksicjncisj;
> double qckcicjpsisj,qckcicjnsisj;
> double qskcicjpsisj,qskcicjnsisj;
--
Shankar.
Gary Scott
It is possible to write highly mnemonic names with 6 characters. I
agree it's too short, but consistency of design helps tremendously and a
quick study of the documentation for the library itself coupled with a
general knowledge of the subject matter makes it reasonably evident:
GSLT = graphics subroutine line <set> type
GSQLT = graphics subroutine query <get> line type
GSLW = graphics subroutine line width
GSQLW = graphics subroutine query line width
I have probably 500-1000 routines of this type virtually memorized
(between GDDM and GINO) with many of the parameter types and value
ranges memorized as well. Once you've been programming this way for 20
years, it isn't difficult at all to read the code. Obviously not easy
for a novice or someone unfamiliar with the libraries to do so. There
are few if any users of Fortran that ever thought 6 characters was
enough and nearly all compilers allowed more. Some compilers had the
abhorent habit of ignoring characters beyond 6, however.
31 is a reasonable minimum in my opinion, but it was put into effect
about a decade ago. If someone wants to change it, formally approach
the standard committee with a proposal.
Jon Skeet
> I have probably 500-1000 routines of this type virtually memorized
> (between GDDM and GINO) with many of the parameter types and value
> ranges memorized as well. Once you've been programming this way for 20
> years, it isn't difficult at all to read the code. Obviously not easy
> for a novice or someone unfamiliar with the libraries to do so.
And that last point is the killer one. How much of the time spent
looking at a program is done when it's in development, compared with
when it's in maintenance? How likely is it that you'll be the one doing
the maintenance? (In some cases, the answer *may* be "very likely", but
in far from all.)
Gary Scott
>
> Gary Scott <sco...@flash.net> wrote:
>
> > I have probably 500-1000 routines of this type virtually memorized
> > (between GDDM and GINO) with many of the parameter types and value
> > ranges memorized as well. Once you've been programming this way for 20
> > years, it isn't difficult at all to read the code. Obviously not easy
> > for a novice or someone unfamiliar with the libraries to do so.
>
> And that last point is the killer one. How much of the time spent
> looking at a program is done when it's in development, compared with
> when it's in maintenance? How likely is it that you'll be the one doing
> the maintenance? (In some cases, the answer *may* be "very likely", but
> in far from all.)
Very likely. When I die, the code goes with me. Virtually everything I
write is an "engineering convenience" tool designed to improve
efficiency of some analysis process. If I don't write them, engineers
will likely just "do it the hard way".
However, I still believe that it is quite easy to study a well designed,
consistently designed API and pick it up very quickly, even with 6
character names. I did this in a very short time when switching from
GDDM (about 500 API routines) to GINO (about 650 API routines). I just
don't personally find this programming methodology that difficult or
error prone (others may have different experiences obviously).
I've never in 23+/- years had an error induced myself because of short
name length restrictions. I've also never witnessed such an error in 20
years as a software/system test engineer with responsibility for
root-cause-analysis, resolution coordination, and metrics generation of
anomalies in 50+ multi-tens to hundreds of million $ projects (well
maybe there was one that I don't remember, but it certainly wasn't a
widespread occurrence).
The Fortran standard committee is overworked as it is, let them focus on
getting "OO" right for now and save this one (internal/external name
lengths) for some future update. If it truly is such a big deal, then
it will be addressed soon enough (relative to its importance).
The end of off-topic stuff (I hope).
>
> --
> Jon Skeet - sk...@pobox.com
> http://www.pobox.com/~skeet
> If replying to the group, please don't mail me at the same time
Roedy Green
wrote or quoted :
>1 is a reasonable minimum in my opinion, but it was put into effect
>about a decade ago.
Assume there is such a thing as the objectively best possible name for
a given variable that could be found my sufficient experiment.
I would think it highly unlikely that in all possible computer
programs that all such names are less than 20 characters. It is thus
arrogant of the designers of languages to enforce very short names.
There was an excuse a long time ago -- compiling long ones could not
be done in typical available RAM.
Today it makes more sense to let the people most familiar with the app
decide on what the optimum name is and how long it should be, subject
only to the practicalities of writing a compiler, e.g. using a single
length byte.
For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.
John English
> I would like it if there were lint-like tools that guarded the
> repository. They would beautify code to project standards, and
> enforce restrictions decided on a per-project basis.
>
> They would enforce the naming rules, see Coding Conventions in the
> Java glossary.
Sounds ambitious. How could a tool decide that a particular arbitrary
method should be called length() rather than getExtent(), for example?
Also you have the inconsistencies that plague the current Java API
(and which are significant due to case sensitivity) such as the name
Hashtable (lowercase t) but HashMap (capital M). How do you decide
where one "word" ends and the next begins within an identifier?
-----------------------------------------------------------------
John English | mailto:j...@brighton.ac.uk
Senior Lecturer | http://www.comp.it.bton.ac.uk/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
Marin David Condic
Guide To The Galaxy"
If you've followed my other comments in this thread, you'll know that I'm in
favor of specific projects deciding for themselves what (and even if) limits
should be imposed on identifiers. I am strongly against language & compiler
designers deciding this issue for you by placing arbitrary and capricious
limits on identifiers. (Beyond what is necessary for practical engineering
concerns. These days, if there is going to be a limit at all {and I don't
think there needs to be} it ought to stem from line lengths in source files
or be set to some really big number that in practice will never be
exceeded - like 256 or 512.)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Roedy Green" <ro...@mindprod.com> wrote in message
news:cubtgtcnrrnkb1nj3...@4ax.com...
Roedy Green
wrote or quoted :
>
>Sounds ambitious. How could a tool decide that a particular arbitrary
>method should be called length() rather than getExtent(), for example?
With today's technology you could not to that. But you could have the
lint tool scream about names such as
getStuff
sEtValue
getqbt
What causes me more trouble than anything else coming
late onto a project is:
1. learning that some words have a specific project meaning.
2. discovering that this vocabulary evolved over time, and that there
are variants. The project vocabulary is inconsistently used.
A lint tool might get people thinking more about this project
vocabulary and using it consistently right from the get go.
For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.
Marin David Condic
of easing the pain than to try to eliminate the problem because I suspect it
is something intractable in human nature. Will the entire world ever learn
to speak English? If they do under force or persuasion, how long before the
English everyone speaks start to diverge into regional dialects? Its been
said the England and the United States are two countries separated by a
common language. :-) Its as good an example as any of why project vocabulary
is going to both become specialized and diverge within pockets of the
project.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Roedy Green" <ro...@mindprod.com> wrote in message
news:utt7hto6rm0o9a8qk...@4ax.com...
Wes Groleau
> One example would be avoiding nested scope to resolve ambiguity.
> Computers have no problem with it, but in many cases it befuddles
> humans.
Computers might not, but compilers are written by humans.
I once spent days trying to find a bug that turned out to
be caused by the compiler confusing a formal parameter
and a global variable several scope levels higher,
And it WAS the most logical name for each.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
Wes Groleau
> I once saw some code which used (in the same namespace) identifiers
> PassThruID and PassThroughIDs. They were apparently introduced
And I once had to use a 200-page set of program documentation,
upper-case only, poor quality, line-printer output, in which
it was very important not to confuse the two modes of the software:
EXECUTIVE and
EXECUTION
The issue is not short or long, it's readability and likelihood
of error. From that viewpoint, I find it hard to understand why,
in the name of "consistency" some folks _vociferously_ castigate
those of us who prefer
View_Preferences_General_Options_Action
over
viewPreferencesGeneralOptionsAction
Chris Smith
> The issue is not short or long, it's readability and likelihood
> of error.
Definitely. You are exactly right.
> From that viewpoint, I find it hard to understand why,
> in the name of "consistency" some folks _vociferously_ castigate
> those of us who prefer
>
> View_Preferences_General_Options_Action
>
> over
>
> viewPreferencesGeneralOptionsAction
Well, this thread is being posted to multiple newsgroups, and I have no idea
where you are posting from. When I wrote the original example, I was
posting from comp.lang.java.programmer, and didn't notice that the thread
was being cross-posted. For that reason, I used standard Java naming
conventions. In other languages, of course, the conventions are
different... some languages leave conventions to be defined on a per-project
(or, more pessimistically, per-developer) basis.
If you're arguing for the View_... form in the Java language, then I'll have
to disagree. I disagree for two reasons: first, under standard conventions,
each type of name in Java has a specific meaning to those reading the code.
It helps people to understand the code *without* prior familiarity with the
vocabulary itself; at least I know whether an instance method is being
invoked on an object, or a class method is being invoked on a class.
Second, these standard conventions allow developers to make reasonable
guesses, and to more easily remember, the names of the methods and fields
they do commonly use. I'd hate to (as I have in C++ on occasion) use
several third party libraries in a project and have to remember that library
A capitalizes method names and uses underscores, but library B starts them
with lower case and no underscores and library C in turn adds a 'C' before
all class names.
That's why consistency is a valid goal. Java *does* have a nearly universal
convention on naming of identifiers, and that makes things much easier, as
long as people follow it.
Chris Smith
Marin David Condic
C/C++ programmers are born with a short pinky-finger on their right hand.
They can't easily make that stretch from the home keys to reach the "_"
character. Since you don't ever attempt to read C/C++ programs - just throw
them out and start over - it never seemed to be a problem to not bother with
readability, and that stretch to the "_" key was causing wrist sprains and
resulting in lost time at work that could have been spent debugging. Hence,
coding standards for these projects took as a productivity step, the
outlawing of underscore characters.
When training former C/C++ programmers to write Ada code, it is important to
make them do exercises to use the ring finger of the right hand to reach the
"_" key. This will help with productivity on Ada projects. Also, don't say
to them the words: "What's a debugger?" - they look at you funny.
pragma Tongue_In_Cheek (Off) ;
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Wes Groleau" <wwg...@ftw.rsc.raytheon.com> wrote in message
news:3B1411D0...@ftw.rsc.raytheon.com...
Roedy Green
<marin.condic...@pacemicro.com> wrote or quoted :
>When training former C/C++ programmers to write Ada code, it is important to
>make them do exercises to use the ring finger of the right hand to reach the
>"_" key. T
Another solution in the Kinesis keyboard that makes the _ key much
easier reach. Or go whole hog and get the DSK version.
See http://mindprod.com/dsk.html#KINESIS
In that same essay is a programmer's DSK keyboard that puts
programmer's more commonly used keys more accessibly with a reference
to some source for keyboard drivers you can modify to roll your own
custom keyboard layout.
Alvaro Segura
> If you're arguing for the View_... form in the Java language, then I'll have
> to disagree. I disagree for two reasons: first, under standard conventions,
> each type of name in Java has a specific meaning to those reading the code.
> It helps people to understand the code *without* prior familiarity with the
> vocabulary itself; at least I know whether an instance method is being
> invoked on an object, or a class method is being invoked on a class.
> Second, these standard conventions allow developers to make reasonable
> guesses, and to more easily remember, the names of the methods and fields
> they do commonly use. I'd hate to (as I have in C++ on occasion) use
> several third party libraries in a project and have to remember that library
> A capitalizes method names and uses underscores, but library B starts them
> with lower case and no underscores and library C in turn adds a 'C' before
> all class names.
>
> That's why consistency is a valid goal. Java *does* have a nearly universal
> convention on naming of identifiers, and that makes things much easier, as
> long as people follow it.
>
> Chris Smith
Anyone likes the MS convention of using "lpstrzLastName" instead of just
"LastName"?
They say it helps you see the type of the variable. But what is a last
name going to be? A floating-point number maybe? :-)
Anyway I do like some consistency like capitalized class names and
lowercase variable names, but not adding letters (my pet is a Dog, not a
CDog or a TDog or a Dog_t).
Larry Kilgallen
> Anyone likes the MS convention of using "lpstrzLastName" instead of just
> "LastName"?
> They say it helps you see the type of the variable. But what is a last
> name going to be? A floating-point number maybe? :-)
I believe they felt they could only go so far in copying VMS and did
not want to include the dollar signs. On VMS QRT$GL_WHATEVER is a
globally accessible longword from the QRT facility. That convention
is quite helpful in Bliss or Macro, but even C has enough type checking
to make the GL_ part unnecessary. Of course the QRT$ tells the facility
(and hence the vendor) to whose namespace it belongs.
Rev. Bob 'Bob' Crispen
on 01 Jun 2001:
>Anyway I do like some consistency like capitalized class names and
>lowercase variable names, but not adding letters (my pet is a Dog,
>not a CDog or a TDog or a Dog_t).
Ages and ages ago, I suggested to the editors of Ada Quality and
Style (as part of the public comment process) that they use the
following convention:
type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
Dog : Dogs;
That is, plural for type names, singular for object names. You'd be
surprised how often that works out. The editors even adopted it as
their recommendation in an early edition of AQ&S.
Evidently some CS professor types were aghast at the simplicity of this
proposal, and a later version of AQ&S changed it to something like
"abstract words for type names, specific words for object names" --
advice that's impossible to understand, much less follow.
I found this culture clash perfectly understandable: I'd come from an
engineering background, so type names like Amperes and Foot_Pounds came
naturally. And too, I had the requirement to produce large volumes of
maintainable code. CS professors are, in my experience, strangers to
both those things. I'm sure there are some dazzling exceptions to this
observation, but all the ones I've met couldn't even get their arms
around the notion that at the end of the day, the sumbitch had to WORK.
Nowadays, I'd probably use My_Dog as the object identifier, but the
good old plural as a type name is still a perfectly good convention,
imho.
Alas, in C and C++ all the really interesting stuff is in the type or
class definitions, and the name you give x in x->foo[i].bar doesn't
make much difference.
--
Rev. Bob "Bob" Crispen
crispen at hiwaay dot net
"We can fix this, but you're gonna need a butter knife, a roll of
duct tape, and a car battery."
Marco Schmidt
Crispen) wrote:
> type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
> Dog : Dogs;
>
>That is, plural for type names, singular for object names. You'd be
>surprised how often that works out. The editors even adopted it as
>their recommendation in an early edition of AQ&S.
I think that's a good idea when dealing with enumeration types.
However, there are cases where I would find it confusing. Example: a
class (type) for a GUI component, a window. If that type's name would
be plural, I'd presume that a variable of that type stores a
collection of those components (buttons, windows, scrollbars). The
other way round, if you make it the convention to always use plural,
there is no more easy way of naming a type that includes a set of
objects.
If the language is case-sensitive, I think it's a good idea to use
dog: Dog; unless there is an obvious way of naming the variable
differently, giving more meaning to what it's supposed to do / be.
Regards,
Marco
--
Java programming tips (last modified 2001-05-17):
http://jiu.sf.net/javatips.html
Ted Dennison
says...
> type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
> Dog : Dogs;
>
>That is, plural for type names, singular for object names. You'd be
>surprised how often that works out. The editors even adopted it as
>their recommendation in an early edition of AQ&S.
That doesn't work too well for quantity nouns (try the same trick with "Sheep"),
or for linked structures or arrays. Personally I prefer to name arrays in the
singular so they look better when individual elements are accesed (their typical
use), but many develpers do not.
I know the "general and specific" rule seems vague, but it is in fact the rule I
settled on for my Ada code. Funny that I independantly settled on the same rule
as all those ivory tower acedemics after a couple of years of experience. :-) I
do think it reads better. If you come across the declaration:
Thread_List : Singly_Linked_List;
..it tells you a lot more relevent information than:
Thread_List : Thread_Lists;
Of course there's nothing stopping you from using both rules:
Thread_List : Singly_Linked_Lists;
But then what's plural here? The type is a singly linked list type, not a group
of them (unless you are into recursive logic). The thing that is plural here is
the *contents* of the list, so I think you'd really have to name it something
more like "Singly_Linked_Nodes", if you want it plural. But we have a name for a
bunch of singly linked nodes; its a "singly linked list". Might as well use that
name.
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
home email - mailto:denn...@telepath.com
Marin David Condic
not always. When I've got a variable that counts up how many of something
I've got, the name naturally wants to reflect that. (Something like
Ripe_Oranges : Integer;) Seeing the plural name under your suggested
convention would lead one to think it is a type name - at least on cursory
inspection or without context. (Ripe_Oranges := Ripe_Oranges + 1; is not
likely to get confused as a type name...)
I tend to use "_Type" at the end of type names - but that is a bit long and
itself subject to confusion or ludicrous afectations. (Sometimes you want an
object called "Message_Type" & then have to go invent some name like
"Message_Category" or violate your convention. And of course
"Message_Type_Type" for the type name looks awfully silly!)
I've never seen a convention that I *really* liked and didn't have problems.
Probably like source code formatting (the great "Capital versus Lower Case
Debate", anyone?) it is probably best to write one down and then stick to
it. Consistency being more important than the exact details of the naming
convention.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Rev. Bob 'Bob' Crispen" <rev...@the.rectory> wrote in message
news:Xns90B35A5F...@207.126.101.100...
Wes Groleau
> > That's why consistency is a valid goal. Java *does* have a nearly universal
> > convention on naming of identifiers, and that makes things much easier, as
> > long as people follow it.
"As long as people follow it" -- a pipe dream. Depending on a convention
that in turn depends on the goodness of human nature is betting Murphy that
his law doesn't apply.
Plus, this convention assumes that knowing the implementation details is
more important than understanding the requirements (abstractions).
One of the reasons Ada works so well is that its users know the opposite
is (usually) true.
Jon Skeet
>
> > > That's why consistency is a valid goal. Java *does* have a nearly universal
> > > convention on naming of identifiers, and that makes things much easier, as
> > > long as people follow it.
>
> "As long as people follow it" -- a pipe dream. Depending on a convention
> that in turn depends on the goodness of human nature is betting Murphy that
> his law doesn't apply.
No-one said anything about *depending* on a convention. *Encouraging* a
convention is a different matter, and in fact almost all experienced
Java programmers I know of *do* seem to follow the conventions, to a
greater or lesser extent.
Wes Groleau
> Ages and ages ago, I suggested to the editors of Ada Quality and
> Style (as part of the public comment process) that they use the
> following convention:
>
> type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
> Dog : Dogs;
>
> That is, plural for type names, singular for object names. You'd be
> surprised how often that works out. The editors even adopted it as
> their recommendation in an early edition of AQ&S.
>
> Evidently some CS professor types were aghast at the simplicity of this
I think it's more a matter of "sounding like English"
> proposal, and a later version of AQ&S changed it to something like
> "abstract words for type names, specific words for object names" --
> advice that's impossible to understand, much less follow.
I would say "easy to understand, not too hard to follow, and makes
the code very readable."
> I found this culture clash perfectly understandable: I'd come from an
> engineering background, so type names like Amperes and Foot_Pounds came
> naturally.
But you ARE following the abstract/specific guideline if you say
type Amperes is .....
Widget_Current : Amperes;
Roedy Green
>That is, plural for type names, singular for object names.
I still have not made up my mind if array names should be plural.
Roedy Green
<marin.condic...@pacemicro.com> wrote or quoted :
>I tend to use "_Type" at the end of type names
I trust you are not a Java programmer from the long list of cross
posts. Here in Java land we have a convention: lower case =
variable/method. upper case = class, all upper case = named constant.
Nice and compact. The only problem is the compiler does not enforce
it. Every once in a while you run into some Bozo who refuses to
follow the convention and it is hell understanding the code because
you can't HELP but unconsciously presume he IS following it even when
you know he is not.
Marin David Condic
By inclination, I'm an Ada programmer. I've fooled with C++ enough to be
familiar with Hungarian notation & basically hated it - except that I'd
agree with you. When you get used to looking at it in a given context, *not*
seeing it tends to throw you. That's why I favor consistency within a
project moreso than some particular naming convention.
Ada identifier style from the Ada Reference Manual is typically words
separated by underscores with capitalization of the first character of each
word. Identifiers_Like_This. Reserved words are always lower case. There is
no widely used or publicized naming convention for Ada beyond the Ada style
guide referenced elsewhere in this thread. AFAIK, there is no detailed
naming convention laid out there - only general guidelines that are like
Mom, Apple Pie & Chevrolet. (all sorts of "goodness" you can't argue with,
but not always real specific.) I've invented naming conventions within
projects and found they can be helpful or a major nuisance - sometimes both
at the same time. My inclination is to stay simple & not impose too much
burden or it won't get followed.
The only real gripe I've got with the C/C++/Java crowd about naming
conventions is that whole business of slurring everything together as if
space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
hyphens or tic-marks or whatever the language uses...) are some kind of
blasphemy in the various sects of C-ism? That, and I never liked any
language or OS that was case-sensitive. (Note: This is personal taste and I
won't even begin to try to justify it with science or logic. I hate it.
That's enough. Its settled. Don't get caught doing it when I'm in charge.)
(Nice little bit of flame-bait there, eh? We can resurrect one of those old
debates that keeps cropping up periodically, right? :-)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Roedy Green" <ro...@mindprod.com> wrote in message
news:ttofhtk7j7ufbtot7...@4ax.com...
Wes Groleau
>
> Wes Groleau <wwg...@ftw.rsc.raytheon.com> wrote:
> >
> > > > That's why consistency is a valid goal. Java *does* have a nearly universal
> > > > convention on naming of identifiers, and that makes things much easier, as
> > > > long as people follow it.
> >
> > "As long as people follow it" -- a pipe dream. Depending on a convention
> > that in turn depends on the goodness of human nature is betting Murphy that
> > his law doesn't apply.
>
> No-one said anything about *depending* on a convention. *Encouraging* a
I believe someone DID say
> It helps people to understand the code *without* prior familiarity with the
> convention is a different matter, and in fact almost all experienced
> Java programmers I know of *do* seem to follow the conventions, to a
> greater or lesser extent.
The eleven people that attended the same Java class I did are not following
this convention unless someone took them aside afterward and explained it to
them.
A written coding, naming, or commenting convention for encoding essential
information that can't be enforced (or isn't) is at best useless (because
you know you can't depend on it and at worst disastrous (because someone
will depend on it when its wrong).
Any convention, enforced or not, for encoding information that is not
important is increasing the chance of being distracted from what IS
important.
Pete Thompson
<marin.condic...@pacemicro.com> wrote:
I hate to cross-post, but...
<snip>
>The only real gripe I've got with the C/C++/Java crowd about naming
>conventions is that whole business of slurring everything together as if
>space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
>hyphens or tic-marks or whatever the language uses...) are some kind of
>blasphemy in the various sects of C-ism? That, and I never liked any
>language or OS that was case-sensitive. (Note: This is personal taste and I
>won't even begin to try to justify it with science or logic. I hate it.
>That's enough. Its settled. Don't get caught doing it when I'm in charge.)
>(Nice little bit of flame-bait there, eh? We can resurrect one of those old
>debates that keeps cropping up periodically, right? :-)
Methinks it would be far more productive to simply let the team members get
their job done rather than worrying about whether they're adhering to your
personal tastes instead of theirs...
Anyways, regarding the underscore. I'm a C/C++ programmer (now learning Java)
and I don't like the underscore because of its location on my keyboard, and it
affects my typing speed. C/C++ are terse languages. Being terse allows you to
do more in a shorter period of time. I like using the i++ statement instead of
i = i + 1. I like being able to code as fast as my train of thought allows
me, and having to pause to type out the underscores can throw me off. Typing
This_Is_A_Variable takes me far longer than typing ThisIsAVariable. Reading
the code isn't much of an issue as long as you capitalize each word in the
variable name. Yes, 'Thisisavariable' would be quite horrible.
Another issue about the underscore's location on the keyboard: I avoid it as
much as possible to cut down on the risks of carpal tunnel. The side of my
right hand is already getting sore from having to reach over for +, =, {, }, \,
backspace, and enter. Throwing the underscore in there would just make it
worse and more painful.
You know, now that I look more closely at my keyboard, it does seem like
there's an awful lot of keys for my right pinky finger to press. Maybe Dvorak
was onto something after all...
Wes Groleau
> Debate", anyone?) it is probably best to write one down and then stick to
> it. Consistency being more important than the exact details of the naming
> convention.
For a naming convention, perhaps. But when one style (such as all caps) is
empirically proven to be significantly less readable than another.....
00001111
00001111 wrote:
> Hi All,
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
>I have folks here in comp.lang.fortran who will die claiming 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...."
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")
>
>
Continuing 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
> Then please respond why, where, when.
AG
"Marin David Condic" <marin.condic...@pacemicro.com> wrote in
message news:9f8b7b$h0e$1...@nh.pace.co.uk...
> Using plurals for type names and singulars for object names can work - but
> not always.
Just think of some other (non-English) language users, are you sure what is
the plural
of something like "fish" in their respective languages?
AG
"Pete Thompson" <blac...@nowhere.somewhere.anywhere.com> wrote in message
news:aqvfhtk583och27tj...@4ax.com...
> On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
> <marin.condic...@pacemicro.com> wrote:
>
> I hate to cross-post, but...
>
> <snip>
>
> >The only real gripe I've got with the C/C++/Java crowd about naming
> >conventions is that whole business of slurring everything together as if
> >space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
> >hyphens or tic-marks or whatever the language uses...) are some kind of
> >blasphemy in the various sects of C-ism? That, and I never liked any
> >language or OS that was case-sensitive. (Note: This is personal taste and
I
> >won't even begin to try to justify it with science or logic. I hate it.
> >That's enough. Its settled. Don't get caught doing it when I'm in
charge.)
> >(Nice little bit of flame-bait there, eh? We can resurrect one of those
old
> >debates that keeps cropping up periodically, right? :-)
I guess you just did:)
>
> Methinks it would be far more productive to simply let the team members
get
> their job done rather than worrying about whether they're adhering to your
> personal tastes instead of theirs...
Well, they do need to talk to each other don't they? And how about the
project
manager just letting "the team members get their job done" ? I guess that
*would*
qualify as the perfect world:)
>
> Anyways, regarding the underscore. I'm a C/C++ programmer (now learning
Java)
> and I don't like the underscore because of its location on my keyboard,
and it
> affects my typing speed. C/C++ are terse languages. Being terse allows
you to
> do more in a shorter period of time.
Like more erorrs? Do you really really claim that your productivity speed is
only
limited by your typing speed? You must be a very exceptional programmer if
your
productive speed is only limited by that ...
> I like using the i++ statement instead of
> i = i + 1. I like being able to code as fast as my train of thought
allows
> me, and having to pause to type out the underscores can throw me off.
Ummm, you are confusing things now - if you speak touch-typing, then
underscores
are no problem - any half-way competenet secretary can do that of course, no
problem.
However, that has nothing to do with the programming.
Besides, your example compares 3 characters to 5 characters (plus perhaps
two spaces
which shouldn't be needed as far as your theory is concerned) So, anyone
really cares
about the [fraction of a second] difference in typing speed as oposed to
hours of design
time?
> Typing
> This_Is_A_Variable takes me far longer than typing ThisIsAVariable.
You must be a very bad typer then:) I note that the whole of your sentence
above contains just 3 underscores but 7 blank spaces. So, how come the
3 underscores took you longer then 7 spaces? Sure, technically speaking
hitting the space bar IS faster then the underscore. *** But *** is it
really
your contention that this is what limits the speed of software development?
> Reading
> the code isn't much of an issue as long as you capitalize each word in the
> variable name. Yes, 'Thisisavariable' would be quite horrible.
If only reading the code was as simple as that... You only need caps to read
the code? Cool...
Jon Skeet
> > No-one said anything about *depending* on a convention. *Encouraging* a
>
> I believe someone DID say
Any references? I can't remember seeing it.
> > It helps people to understand the code *without* prior familiarity with the
>
> > convention is a different matter, and in fact almost all experienced
> > Java programmers I know of *do* seem to follow the conventions, to a
> > greater or lesser extent.
>
> The eleven people that attended the same Java class I did are not following
> this convention unless someone took them aside afterward and explained it to
> them.
If they were attending a Java class, I *suspect* I wouldn't call them
experienced Java programmers.
The more experienced you get, the more other people's code you read -
and as almost all the code you read (especially Sun's, obviously) use
the same conventions, it makes sense to adopt them. It helps not to have
to remember where you got a package from in order to easily work out
what the methods are likely to be called.
> A written coding, naming, or commenting convention for encoding essential
> information that can't be enforced (or isn't) is at best useless (because
> you know you can't depend on it and at worst disastrous (because someone
> will depend on it when its wrong).
No, at best it's very helpful, as it means I can read other people's
code faster than I would if they didn't follow the same convention as I
do.
In the middle it's reasonably helpful, as if someone uses *a* convention
but it's not the same as me, then I can get to grips with their
convention then I can learn to read their code quickly too.
The worst situation is when someone doesn't follow a convention *at
all*, changing capitalisation etc at a whim - at that stage, you have to
look up method names etc every time you want to use them.
> Any convention, enforced or not, for encoding information that is not
> important is increasing the chance of being distracted from what IS
> important.
So you believe that
package TeST;class SHowArGS{public static void main (String[]ARgS){for
(int SOMeThINg=0;SOMeThINg<ARgs.length;SOMeThINg++)System.out.println
(ARgS[SOMeThINg]);}}
is *more* likely to create distraction than:
package test;
class ShowArguments
{
public static void main (String [] args)
{
for (int i=0; i < args.length; i++)
System.out.println (args[i]);
}
}
Sorry, but I think that's crazy.
Edward Rosten
> Crispen) wrote or quoted :
>
>>That is, plural for type names, singular for object names.
>
>
> I still have not made up my mind if array names should be plural.
This is probably another of those holy war type things, but they always
made sense to me as singular, since to me English works more like that.
Eg, if you had a bunch of objects (apples, for example) in a row, you
would refer to apple[5] as the 5th apple, not the 5th apples. That's
why I would write the array as apple[] not apples[].
-Ed
--
(You can't go wrong with psycho-rats.) (u98ejr)(@)(ecs.ox)(.ac.uk)
/d{def}def/f{/Times-Roman findfont s scalefont setfont}d/s{10}d/r{roll}d f 5 -1
r 230 350 moveto 0 1 179{2 1 r dup show 2 1 r 88 rotate 4 mul 0 rmoveto}for/s 15
d f pop 240 420 moveto 0 1 3 {4 2 1 r sub -1 r show}for showpage
Simon Wright
> On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
> <marin.condic...@pacemicro.com> wrote:
> >The only real gripe I've got with the C/C++/Java crowd about naming
> >conventions is that whole business of slurring everything together as if
> >space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
> >hyphens or tic-marks or whatever the language uses...) are some kind of
> >blasphemy in the various sects of C-ism? That, and I never liked any
> >language or OS that was case-sensitive. (Note: This is personal taste and I
> >won't even begin to try to justify it with science or logic. I hate it.
> >That's enough. Its settled. Don't get caught doing it when I'm in charge.)
> >(Nice little bit of flame-bait there, eh? We can resurrect one of those old
> >debates that keeps cropping up periodically, right? :-)
>
> Methinks it would be far more productive to simply let the team
> members get their job done rather than worrying about whether
> they're adhering to your personal tastes instead of theirs...
The point Marin made (in a bit you snipped, I think) was that we're
talking about a programming *team*. A team will be much more effective
if all the members are cooperating. Your idea seems to just accept
that running a programming team is like herding cats.
The job of the team is not to produce lots of modules that someone
else has to fit together. The job is to produce an integrated working
program. You will have to come to a common understanding of the
software architecture, and this isn't just about whose job it is to
manage deallocation or how we deal with threads or what design
patterns we use, it also includes common stylistic conventions.
> Anyways, regarding the underscore. I'm a C/C++ programmer (now
> learning Java) and I don't like the underscore because of its
> location on my keyboard, and it affects my typing speed. C/C++ are
> terse languages. Being terse allows you to do more in a shorter
> period of time. I like using the i++ statement instead of i = i +
> 1. I like being able to code as fast as my train of thought allows
> me, and having to pause to type out the underscores can throw me
> off. Typing This_Is_A_Variable takes me far longer than typing
> ThisIsAVariable.
Tough, because ..
> Reading the code isn't much of an issue as long as
> you capitalize each word in the variable name. Yes,
> 'Thisisavariable' would be quite horrible.
.. most code is read far more often than it's written. Your job isn't
just to work in a way that makes _you_ most comfortable, it's to
support what your employer needs in the future.
If you want your work to be thrown away next time maintenance is
needed, go ahead .. think of your successors, looking for a picture of
you so they can stick black pins in it.
Of course, if you're in a throwaway environment, all these engineering
considerations are out of the window.
Simon Wright
I suspect it's a matter of whether the thing we want to name is
fungible or not :-)
Your ampere is quite indistinguishable from my ampere. Your metre is
the same as mine. So when we're naming quantities it seems to come
quite naturally to use plurals:
type Watts is new Float;
Present_Dissipation : Watts;
and indeed I found myself the other day doing that perfectly
naturally.
On the other hand, when you're discussing things that are
distinguishable, the use of plurals gets pretty uncomfortable. It's
the same distinction as between 'less' and 'fewer', I think.
If you think of a department store, you might be interested in the
number of employees:
sybtype Employees is Natural;
Staff_Number : Employees;
but if you are interested in Alice, Bob and Carol specifically it
seems very odd indeed to say
type Employees is record
..
end record;
Alice : Employees;
if for no other reason than that you also need a word to name the type
'collection of employees' (the database table you keep the employee
records in, for example).
I'm not so sure about enumeration types. Seems that the Dogs type
above would be more natural as Dog_Kind or, in this universe, Breed. I
agree you get into trouble with naming variabls of type Breed
(The_Breed, anyone!). [I do somewhat question the validity of
Dog_Pound_Dog; I think it should probably be Mongrel, even sheepdogs
may find themseleves in the pound.]
However ..
I made the distinction between 'less' and 'fewer' above. I get the
impression that fewer and fewer people would understand what I mean
there, and the last thing I want is to send the team off into a half
hour of navel gazing every time someone needs to name a new type!
Perhaps a simpler rule set that meant they only needed to take 15
minutes would be better .. note, I think names are important, it's
worth spending time on them, naming is real work, you need Name
Police, it's just not the only thing to think about!
-Simon
Shmuel (Seymour J.) Metz
at 10:14 AM, "Marin David Condic"
<marin.condic...@pacemicro.com> said:
>When training former C/C++ programmers to write Ada code, it is
>important to make them do exercises to use the ring finger of the
>right hand to reach the "_" key. This will help with productivity on
>Ada projects. Also, don't say to them the words: "What's a debugger?"
>- they look at you funny.
When I programmed in Ada we had a debugger. We also used names long
enough to be intelligible to other programmers. Use opaque
abbreviations and you wouldn't make it through code review.
"What's a code review?"
--
-----------------------------------------------------------
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
Team OS/2
Team PL/I
Any unsolicited commercial junk E-mail will be subject to legal
action. I reserve the right to publicly post or ridicule any
abusive E-mail.
I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me. Do not reply to
spam...@library.lspace.org
-----------------------------------------------------------
Marin David Condic
length. All object identifiers will be exactly 16 characters in length. Its
easy to check & enforce automatically. Its visually distinctive even if you
have a perverted programmer who likes names like: oooo0000OOOOoooo and
ll11ll11llll1111. It is an uncomplicated convention that anybody can
understand. Nobody has to go off and gaze at their navel for an hour to come
up with a name for something - pick anything and truncate to fit. It works
for any language as well.
Now I think I should have that highly caffeinated cup of coffee & engage my
brain - lest I tempt someone to actually take me seriously here & develop a
coding standard like this. :-)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Simon Wright" <si...@pushface.org> wrote in message
news:x7vn17r...@smaug.pushface.org...
Marin David Condic
on. I don't even know how. :-)
Here's a thing: Debuggers in and of themselves are not a bad thing. This is
especially true with embedded systems where you need a debugger (or maybe
more properly a "monitor") in order to watch the code run - something often
invisible within an embedded machine. The thing is that in my experience,
use of C/C++ means you end up heavily reliant on the debugger in the act of
code development because you just have no choice.
I've spent probably over 15 years in active, full time, professional Ada
development and almost never used a debugger. (Monitors in embedded machines
being a sort-of exception.) When I started using MSVC++ on a regular, full
time basis, I was impressed with the capabilities of the debugger that came
with it. It *had* to be impressive, because you *had* to use it to get the
code working. There may be debuggers that work with Ada that have ten times
the capability. I just couldn't tell you because I never needed one to get
an Ada program working. Ever. (Maybe that's just because I'm so brilliant,
but I don't think so. I think its because the compiler catches all the
stupid mistakes up front or at least gives you runtime exceptions if it has
to wait until then to detect the error.)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in
message news:3b1ad864$4$fuzhry$mr2...@va.news.verio.net...
Ted Dennison
>
>... C/C++ are terse languages. Being terse allows you to
>do more in a shorter period of time. I like using the i++ statement instead of
Yowch. You lost me right there. Typing in the program is nowhere *near* the most
time-consuming part of developing software. That distinction belongs to the
"getting it to work" phase, along with maintanence in general. The focus needs
to be on doing things that will make those phases go quicker.
This statement is a perfect illustration of how the ancient design of C
encourages developers to worry about optimizing the wrong things. Back in '72
when C was designed, the size of a source file was a real issue, and programs
were generally much smaller (and thus simpler to get running). But none of this
is true today.
Marin David Condic
in comparison to other phases that it falls below the noise level and is
nearly undetectable. You may spend a fair amount of time *staring* at the
code you are writing and *reasoning* about the code and so forth, but if one
thinks the *typing* of the code is a significant part of the productivity
equation, I'd want to challenge that and ask for some actual test data.
Attempting to optimize typing time just isn't going to pay off in any
business case.
Except for one-shot, throw-away programs or extremely small, near-trivial
programs, I think almost any study would show that the time spent reading
the code far exceeds the time spent writing it - including the
staring/reasoning part. (I'd exclude requirements and design time since
these are basically language-independent activities. Test and debug time
probably are significantly impacted by language choice - at least I had data
to indicate this was true in one problem domain.) Hence the reason Ada was
designed with readability in mind rather than attempting to save keystrokes.
That realization and experience has impacted the way I write C code & I
think most of my associates appreciate the fact that I eschew obfuscation
when writing in C. It may not be as "terse" as their code, but it is a heck
of a lot easier for them to figure out what my code is up to than the other
way around. (And when did "terse" become of value in and of itself, anyway?
Why should it be a goal to be strived for?)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin....@pacemicro.com
Web: http://www.mcondic.com/
"Ted Dennison" <denn...@telepath.com> wrote in message
news:IsNS6.3800$v4.1...@www.newsranger.com...
Ray Blaak
> If you come across the declaration:
>
> Thread_List : Singly_Linked_List;
>
> ..it tells you a lot more relevent information than:
>
> Thread_List : Thread_Lists;
More information yes, but to me this is information that the client should
*not* be aware of when using it, ideally speaking.
What the client should be aware of is that Thread_Lists (or Thread_List --
that is not my point here) is a container of threads such that one can get the
first one, maybe the last, and the next. Whether that is single or doubly
linked or even linked at all should be irrelevant to the client.
That is, plural or not, the name should indicate what the object is,
abstractly speaking, not how it is implemented.
With regards to plurality, what guides me is if the name indicates accurately
how can something be used. Do you have a list of threads or a list of thread
lists? If the former than my preference is for:
Pending_Threads : Threads;
That is, I try to avoid the use of things like "List" in a type name, so as to
free myself from dependencies on a particular implementation. (e.g. what it is
changed to a hash table or array or something? "List" would be confusing to
maintainers). But I do have a collection of threads, accessible somehow, and
that is the important point.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@infomatch.com The Rhythm has my soul.
Roedy Green
<marin.condic...@pacemicro.com> wrote or quoted :
> Hence the reason Ada was
>designed with readability in mind rather than attempting to save keystrokes.
There is a general rule though, that a terser program makes it easier
to see the big picture. You can get more of it on screen at once.
Use of smaller methods so can easily see the whole flow of a method in
a single screen full, without getting bogged in too much detail,
really helps.
Rapid navigation tools similarly help. See
http://mindprod.com/scid.html.
What I find so strange is something as simple as variable
sized/coloured {} and () to make visual balancing easier still has not
caught on.
Perhaps if we had more females in the tool design process they would
not be so macho about insisting on making programming uncomfortable
and difficult.
Roedy Green
<marin.condic...@pacemicro.com> wrote or quoted :
>I've spent probably over 15 years in active, full time, professional Ada
>development and almost never used a debugger.
I'm finding a similar thing with Java. I almost never use the
debugger anymore. I was used to C/C++ coding where I wanted to WATCH
every line of code run to make sure it did not do anything unexpected
on me before I would release it on the unsuspecting public.
The equivalent sort of thing I do now in Java is a re-read top to
bottom of all the code to make sure everything is still in sync, and
to prune out old junk no longer needed.
Larry Kilgallen
> On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
> <marin.condic...@pacemicro.com> wrote or quoted :
>
>> Hence the reason Ada was
>>designed with readability in mind rather than attempting to save keystrokes.
>
And where is this rule written ? Most programs I have seen can be made
more clear by tripling their length with well-written comments (once
good identifier names have been chosen).
> to see the big picture. You can get more of it on screen at once.
> Use of smaller methods so can easily see the whole flow of a method in
> a single screen full, without getting bogged in too much detail,
> really helps.
Subprograms are important to separate logical functions, but using
them just in pursuit of getting the whole thing to show on a screen
of some arbitrary size is much less valuable.
> What I find so strange is something as simple as variable
> sized/coloured {} and () to make visual balancing easier still has not
> caught on.
What makes you say it has not caught on ?
Several editors do syntax coloring for Ada, and the Alpha editor also
does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
Postscript, Scheme, SQL, Tcl, TeX, LaTeX and LaTeX2e.
BBEdit does it for HTML JavaScript, Perl, PHP3, XHTML and XML.
Of those two, BBEdit is more popular, but someone else would have to
speak to the capabilities of various Emacs implementations.
Roedy Green
Kilgallen) wrote or quoted :
>> There is a general rule though, that a terser program makes it easier
>
>And where is this rule written ?
Two places. See Byte Magazine 1986 October, my article on Abundance.
See also http://mindprod.com/unmain.html an essay on how to write
unmaintainable code.
Roedy Green
Kilgallen) wrote or quoted :
>> What I find so strange is something as simple as variable
>> sized/coloured {} and () to make visual balancing easier still has not
>> caught on.
>
>What makes you say it has not caught on ?
>
>Several editors do syntax coloring for Ada, and the Alpha editor also
>does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
>Postscript, Scheme, SQL, Tcl, TeX, LaTeX and LaTeX
I did not explain clearly. I don't just mean making all {} some
colour different from the rest of text, but to make them match
pairwise in increasing size with nesting depth, possibly also using
different shade with matching pairs the same shade.
See http://mindprod.com/bali.html where you can see some examples of
what it might look like.
Larry Kilgallen
> On 4 Jun 2001 19:40:29 -0500, Kilg...@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :
>
>>
>>And where is this rule written ?
>
>
> See also http://mindprod.com/unmain.html an essay on how to write
> unmaintainable code.
Since these are both your work, I think a more open statement than
"There is a general rule" would have been "I have a general rule".
Larry Kilgallen
> On 4 Jun 2001 19:40:29 -0500, Kilg...@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :
>
>>> sized/coloured {} and () to make visual balancing easier still has not
>>> caught on.
>>
>>What makes you say it has not caught on ?
>>
>>Several editors do syntax coloring for Ada, and the Alpha editor also
>>does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
>
> I did not explain clearly. I don't just mean making all {} some
> colour different from the rest of text, but to make them match
> pairwise in increasing size with nesting depth, possibly also using
> different shade with matching pairs the same shade.
Increasing depths are taken care of automatically by prettyprinters
(a misnomer, but that is what a lot of people call formatting programs).
In Ada those that are standalone are actually begin/end pairs, and I
always find the indentation to be sufficient. If it is not I view it
as a danger signal for excessive complexity.
I presume you are not worried about matching in something short like
an array reference or function call:
Answer := Correct_Answer ( Answer_Number ( Index ) );
Larry Kilgallen
> See also http://mindprod.com/unmain.html an essay on how to write
> unmaintainable code.
That is a good essay, though.
Roedy Green
Kilgallen) wrote or quoted :
>Since these are both your work, I think a more open statement than
>"There is a general rule" would have been "I have a general rule".
Being dreadfully modest, I doubt there are few other people in the
world who, when they can't fall asleep at night worry about why the
world's computer programs are not maintainable. It has been a bit of
an obsession of mine for a long time, going back before some of you
were born. I have done quite a bit of experimenting trying to find
out what makes programs maintainable and unmaintainable. Few others
in the known universe have come near the number of posts I have done
preaching the gospel of maintainability and the path to true
salvation.
Even the esteemed Bruce Eckel said I should write a book on the topic.
Blaikie
> colour different from the rest of text, but to make them match
> pairwise in increasing size with nesting depth, possibly also using
> different shade with matching pairs the same shade.
only a finite number of possible shades, yet an infinite number of possibly
nested brakets, a quite usefull solution is used in Forte4Java, whenever the
text cursor passes over a braket, both the begin and matching end brackets
go bold for a short time.
db
Blaikie
arbitrary measure of code length, especially seeing as different ppls
resolutions effect what a 'screen' of code is), u only need to seperate
resused code into seperate methods, if u have one method that is 10 pages
long, but there is no reptition and the code is used nowhere else, why make
it into seperate methods? yes a few comments, and alot of thought about the
elegance of the algorithm should be used, but splitting a method just for
the sake of length seems a bit pointless (sometimes, other times if a
certain part of the code serves an independant function to the rest of the
code, yet is still only used once, it may still be nice to seperate it)
db
Jon Skeet
There *is* a reason to do it - it makes the overall structure easier to
read. For instance, in many cases those 10 pages of code can be isolated
into easily described blocks that are independent of the other bits. Say
you get one of those per page - then the main method can become just 10
lines long, giving a very easy overview. It then becomes very easy to
pinpoint which piece of the code performs any particular function.
It doesn't always work like that, but it can. Code repetition isn't the
only reason for refactoring.
Blaikie
> > the sake of length seems a bit pointless (sometimes, other times if a
> > certain part of the code serves an independant function to the rest of
the
> > code, yet is still only used once, it may still be nice to seperate it)
> only reason for refactoring.
i agree, thats why i put the exception in the brakets at the end, but there
are times when the code just simple isn't divisible, which is the point i
was making, yes if u have a routine that reads in and creates a simple
object., but one of its fields is an int, yes, have a seperate method that
reads and parses an int, but such a case is not always possible
db
Jon Skeet
Not *always* possible - but your inclusion of it just in brackets makes
it appear that you believe it's normally the case.
I'd suggest that *very* few methods which are ten pages of code which
*can't* be broken down further are well-designed.
Blaikie
> it appear that you believe it's normally the case.
> I'd suggest that *very* few methods which are ten pages of code which
> *can't* be broken down further are well-designed.
quite probably, neways the point is, we agree, its just a matter of degrees
and probability of atomic code
db
Georg Bauhaus
: Wes Groleau <wwg...@ftw.rsc.raytheon.com> wrote:
: The worst situation is when someone doesn't follow a convention *at
: all*, changing capitalisation etc at a whim - at that stage, you have to
: look up method names etc every time you want to use them.
: > Any convention, enforced or not, for encoding information that is not
: > important is increasing the chance of being distracted from what IS
: > important.
: So you believe that
: package TeST;class SHowArGS{public static void main (String[]ARgS){for
: (int SOMeThINg=0;SOMeThINg<ARgs.length;SOMeThINg++)System.out.println
: (ARgS[SOMeThINg]);}}
: is *more* likely to create distraction than:
What is important is not just syntax and letter case. E.g.,
I've had no difficulties in reading and understanding your
example in the form above, left to right as in books.
(After all, letter case is an invention that came relatively
late in the use of latin alphabets, sometime after carolingean
minuscules in the 9c, I believe. (Side note: Serif Courier is very different
from sans serif Windoze Fixedsys, so whether it is easy
to distinguish characters in Marin's ll11l1 depends on the font...))
There is a distinction to be made between reading and inspecting.
There is no use in using a tabular
layout when it is not useful as
it does not at all help readers,
but it is useful when you are inspecting interface definitions, say.
: package test;
: class ShowArguments
: {
: public static void main (String [] args)
: {
: for (int i=0; i < args.length; i++)
: System.out.println (args[i]);
: }
: }
(Due to a local convention that what
carries meaning in a function declaration is return type,
name, and arguments, to a larger extent than modifiers,
I was distracted by the leading modifier "clutter", and
by the same convention, where are those helpful brackets
around the non-block statement? Ah, those correct width
stripes on ties arguments ... :-)
By the way, if you like being shocked, have a look at tex.web,
the file that has the sources for TeX in it. Still not an
unmaintainable program, which leads me to the conclusion that
the programmer's responsability is to write source code that
can be understood by others, _possibly with the help of
tools(used by them)_ to make sources fit the most productive taste.
Seems difficult to arrive at this idea, given that HTML has
first brought us absurdities like font-tags, instead of style
sheets. :-)
Georg Bauhaus
---
Microsoft Windows--a whole new perspective on information hiding!
John English
> Anyways, regarding the underscore. I'm a C/C++ programmer (now learning Java)
> and I don't like the underscore because of its location on my keyboard, and it
> do more in a shorter period of time. I like using the i++ statement instead of
> me, and having to pause to type out the underscores can throw me off. Typing
> the code isn't much of an issue as long as you capitalize each word in the
> variable name. Yes, 'Thisisavariable' would be quite horrible.
I find ThisIsAVariable harder to read than This_Is_A_Variable, and IMHO
readability is much more important than coding speed (unless it's a
10 line noddy to be thrown away in an hour's time). As far as typing
speed is concerned, I would have thaought that all the asterisks and
plusses and curly brackets in C/C++/Java would be more of an issue...
Mind you, I type one-fingered (but very quickly after 30 years of
practice :-) so I find I'm more keyboard-layout-insensitive than a
real typist.
-----------------------------------------------------------------
John English | mailto:j...@brighton.ac.uk
Senior Lecturer | http://www.comp.it.bton.ac.uk/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
Jon Skeet
> Jon Skeet (sk...@pobox.com) wrote:
> : Wes Groleau <wwg...@ftw.rsc.raytheon.com> wrote:
>
> : The worst situation is when someone doesn't follow a convention *at
> : all*, changing capitalisation etc at a whim - at that stage, you have to
> : look up method names etc every time you want to use them.
>
> : > Any convention, enforced or not, for encoding information that is not
> : > important is increasing the chance of being distracted from what IS
> : > important.
>
> : So you believe that
>
> : package TeST;class SHowArGS{public static void main (String[]ARgS){for
> : (int SOMeThINg=0;SOMeThINg<ARgs.length;SOMeThINg++)System.out.println
> : (ARgS[SOMeThINg]);}}
>
> : is *more* likely to create distraction than:
>
> What is important is not just syntax and letter case. E.g.,
> I've had no difficulties in reading and understanding your
> example in the form above, left to right as in books.
> (After all, letter case is an invention that came relatively
> late in the use of latin alphabets, sometime after carolingean
> minuscules in the 9c, I believe. (Side note: Serif Courier is very different
> from sans serif Windoze Fixedsys, so whether it is easy
> to distinguish characters in Marin's ll11l1 depends on the font...))
Why does when the date of the invention of letter case have anything to
do with readability *now*? I found it *much* harder to write the above
than the conventional version, as every time I wanted to use an
argument, I had to *check* the case rather than being able to accurately
guess it.
> There is a distinction to be made between reading and inspecting.
I'm not *entirely* sure what you mean here. When talking about human-
readability of code, I suspect that "reading" is always used to mean
"inspecting".
> There is no use in using a tabular
> layout when it is not useful as
> it does not at all help readers,
> but it is useful when you are inspecting interface definitions, say.
True. When considering the readability of code, however, I suspect it's
always helpful.
John English
> That's why consistency is a valid goal. Java *does* have a nearly universal
> convention on naming of identifiers, and that makes things much easier, as
> long as people follow it.
"Nearly". It's a pity about examples in the standard API like
"Hashtable" as compared to "HashMap"... I've forgotten the number
of times I've seen students adhere to the convention and write
HashTable, and then sigh deeply and waste several minutes looking
it up in the API reference when the compiler starts bellyaching.
John English
> There is a general rule though, that a terser program makes it easier
> to see the big picture. You can get more of it on screen at once.
> Use of smaller methods so can easily see the whole flow of a method in
> a single screen full, without getting bogged in too much detail,
> really helps.
I agree that you should be able to see a whole unit (method, function,
whatever) on a single screen/page, but making the code "terser" just
means you can get twice as much stuff in the same space, so there's
twice as much complexity to absorb and it's twice as cryptic too.
The answer isn't terseness, it's abstraction. It's about breaking
things into bite-sized modules, not trying to cram as much stuff
as possible into an arbitrarily-chosen amount of space. Otherwise,
you could achieve a similar effect by removing unnecessary white
space (i.e. indentation and line breaks), which otherwise "wastes"
about 50% of the available screen area in most programs...
John English
> Being dreadfully modest, I doubt there are few other people in the
> world who, when they can't fall asleep at night worry about why the
I beg to differ.
Philip Anderson
> Typing
> This_Is_A_Variable takes me far longer than typing ThisIsAVariable.
But I for one would type "this_is_a_variable" in (case-insensitive) Ada,
and let the editor capitalise each word for me; three '_' to type but I
save on use of the shift key.
--
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbrân, Cymru/Wales
Ted Dennison
>
>On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
><marin.condic...@pacemicro.com> wrote or quoted :
>
>> Hence the reason Ada was
>>designed with readability in mind rather than attempting to save keystrokes.
>
>There is a general rule though, that a terser program makes it easier
>to see the big picture. You can get more of it on screen at once.
So by this rule, APL produces the most readable code?
Clearly there's a bit more to it than just physical size. I'd agree that the
most readable code might be split up into small routines. But it doesn't follow
that you can therefore make your code more readable just like those other small
routines by compressing your large routine into a small-lookng one without
restructuring anything. Being able to suck your gut in and hold your breath for
a while doesn't mean you're not overweight.
Ted Dennison
>
>rather than making every method less than a screen long (again a rather
>arbitrary measure of code length, especially seeing as different ppls
>resolutions effect what a 'screen' of code is), u only need to seperate
>resused code into seperate methods, if u have one method that is 10 pages
>long, but there is no reptition and the code is used nowhere else, why make
>it into seperate methods? yes a few comments, and alot of thought about the
Any routine that is 10 pages long is doing a *lot* of stuff. Perhaps in
high-level terms you can express what it is doing succinctly, but at the level
that the routine actually operates, you can't. If you can't express what the
routine is doing succinctly, at the level it operates, then a maintainer is
going to have to read through 10 screens of code to figure it out themselves.
The author might even get confused on the subject from time to time. Bugs are
going to be tougher to spot and track down because you'll have to rethink the
subject of exactly what the routine is supposed to be doing every time you
revisit it.
Additionally, I find that I often end up with *less* code when I split a big
routine up into smaller ones. The data flow is also easier to follow because
what were routine-wide globals that could be modified anywhere within 10 screens
of code often turn into parameters that only go into one or two of the new
smaller routines. Its also much better commented, becuase I always have a header
comment for every routine describing its purpose and what it does.
Ted Dennison
>
>Mind you, I type one-fingered (but very quickly after 30 years of
>practice :-) so I find I'm more keyboard-layout-insensitive than a
>real typist.
I can actually touch-type. But I've found its *very* rare that this skill comes
in handy while writing code. Perhaps there are some people out there who *think*
in C or Ada, but I have to stop every couple of lines to translate or
strategize.
Jon Skeet
> In article <3B1CC17D...@brighton.ac.uk>, John English says...
> >
> >Mind you, I type one-fingered (but very quickly after 30 years of
> >practice :-) so I find I'm more keyboard-layout-insensitive than a
> >real typist.
>
> I can actually touch-type. But I've found its *very* rare that this skill comes
> in handy while writing code. Perhaps there are some people out there who *think*
> in C or Ada, but I have to stop every couple of lines to translate or
> strategize.
Interesting. This doesn't tend to be the way I work in Java. Someone
will give me a problem, and I'll spend the next couple of days reading
news, surfing the web, playing games, etc - occasionally consciously
thinking about the problem, and subconsciously thinking about it most of
the time (I believe - obviously I can't easily measure that!)
After that couple of days, I'll sit at a keyboard and write a large
block of code. I may stop every so often if I'm writing a block of code
which needs thinking about at a low level, but I relatively rarely need
to reconsider a high-level design decision - at that stage, anyway. (Of
course it all changes when the original requirements change!)
To that end, my overall coding speed *does* have a slight bottleneck in
typing speed, but I don't believe it's significant.
James Kanze
> On Fri, 1 Jun 2001 11:09:30 -0400, "Marin David Condic"
> <marin.condic...@pacemicro.com> wrote or quoted :
> >I tend to use "_Type" at the end of type names
> I trust you are not a Java programmer from the long list of cross
> posts. Here in Java land we have a convention: lower case =
> variable/method. upper case = class, all upper case = named
> constant.
> Nice and compact. The only problem is the compiler does not enforce
> it. Every once in a while you run into some Bozo who refuses to
> follow the convention and it is hell understanding the code because
> you can't HELP but unconsciously presume he IS following it even
> when you know he is not.
Another problem is that it doesn't read well over the telephone. One
of my criteria for a good naming convention is that people from the
project should be able to talk about the code over the telephone with
no ambiguities.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627