Re: Long names are doom ?

Re: Long names are doom ?

[robin]

jschauma@netmeister.org (Jan Schaumann) writes: > * Chris Smith wrote:
> >  "00001111" <00001111@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.

er -- unreadable.

view_Prefs_Gen_Opt_Action is better style.

> -Jan
> -- 
> Jan Schaumann 
> http://www.netmeister.org

Re: Long names are doom ?

[Jonas Lindstr�m]

"robin" <robin_v@bigpond.nospam.com> wrote in message
news:BFDP6.20482$hV3.23034@newsfeeds.bigpond.com...
> jschauma@netmeister.org (Jan Schaumann) writes: > * Chris Smith wrote:
> > >  "00001111" <00001111@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.
>
> er -- unreadable.
>
> view_Prefs_Gen_Opt_Action is better style.

That depends on which language you are using.

/Jonas L

Re: Long names are doom ?

[robin]

Patricia Shanahan <pats@acm.org> writes: > 
> 
> 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

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

Re: Long names are doom ?

[Chris Smith]

"00001111" <00001111@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.
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

Re: Long names are doom ?

[Jan Schaumann]

* Chris Smith wrote:
>  "00001111" <00001111@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

Re: Long names are doom ?

[(null)]

In article <slrn9grkuk.10u.jschauma@www.netmeister.org>,
Jan Schaumann <jschauma@netmeister.org> wrote:
>* Chris Smith wrote:
>>  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.


viewPrefsGenOptAction?  Do you mean soething like a procedure 
to VIEW PREFerences implemented as a GENeric unit and the procedure 
has an OPTional ACTION.

The moral of the story, all names are "readable" to the author.
The real test is what other people might think.  Abbreviations are
good, but only if they aren't ambiguous. 


-- 
=======================================================================
 Life is short.                  | Craig Spannring 
      Bike hard, ski fast.       | cts@internetcds.com
 --------------------------------+------------------------------------

Re: Long names are doom ?

[Patricia Shanahan]

"(null)" wrote:
> 
> In article <slrn9grkuk.10u.jschauma@www.netmeister.org>,
> Jan Schaumann <jschauma@netmeister.org> wrote:
> >* Chris Smith wrote:
> >>  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.
> 
> viewPrefsGenOptAction?  Do you mean soething like a procedure
> to VIEW PREFerences implemented as a GENeric unit and the procedure
> has an OPTional ACTION.

Perhaps it will VIEW the PREFerenceS and GENerate the OPTimal ACTION?

Why did "Preferences" get to keep the final "s", being abbreviated to
"Prefs", but "Options" went to "Opt"? Faced with that identifier, in its
original meaning, I would keep putting the "s" on both, or dropping it
from both, or getting it the wrong way round.

> 
> The moral of the story, all names are "readable" to the author.
> The real test is what other people might think.  Abbreviations are
> good, but only if they aren't ambiguous.
> 
> --
> =======================================================================
>  Life is short.                  | Craig Spannring
>       Bike hard, ski fast.       | cts@internetcds.com
>  --------------------------------+------------------------------------

Re: Long names are doom ?

[Charles Demas]

In article <slrn9grkuk.10u.jschauma@www.netmeister.org>,
Jan Schaumann <jschauma@netmeister.org> wrote:
>* Chris Smith wrote:
>>  "00001111" <00001111@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.

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.
  demas@tiac.net |  \___/  | http://www.tiac.net/users/demas

Re: Long names are doom ?

[Larry Elmore]

00001111 wrote:
> 
>  Hi All,
> 
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
> 
> Then please respond  why, where, when.
> I have folks here in comp.lang.fortran who 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.

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

Re: Long names are doom ?

[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

Re: Long names are doom ?

[Roedy Green]

On 25 May 2001 03:21:04 GMT, Patricia Shanahan <pats@acm.org> wrote or
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.

Re: Long names are doom ?

[Jim Monty]

Patricia Shanahan <pats@acm.org> wrote:
> 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

    pats@acm.org?

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
monty@primenet.com
Tempe, Arizona USA

Re: Long names are doom ?

[Jon Skeet]

Jim Monty <monty@primenet.com> wrote:
> 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 - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Larry Kilgallen]

In article <9ekth1$49o$1@nnrp1.phx.gblx.net>, Jim Monty <monty@primenet.com> writes:

> Would you be "less memorable" if you were
> 
>     Patricia_Shanahan@Association_of_Computing_Machinery.Organization
> 
> instead of simply
> 
>     pats@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.

Re: Long names are doom ?

[John]

> 
> Would you be "less memorable" if you were
> 
>     Patricia_Shanahan@Association_of_Computing_Machinery.Organization
> 
> instead of simply
> 
>     pats@acm.org?

Actually, both are not that easy. 

> 
 But does
> that make it harder for them to remember the URL www.mtv.com?

I doubt that my code is going to become as popular as mtv or www or
.com.

If there were standard abbreviations or popular abbreviations or
common ones, I think people would understand those. One way to get a
happy medium is to use
Descriptive class names or somewhere in the code where you can figure
out what
the object is. 

AbbreviationConfabulator ac = new AbbreviationConfabulator(); //is not
bad style.
OR
public static String LCD = "Least Common Denominator"; 
sheesh or at least comments. (that's what they're there for)
The javadoc is a neat invention. someday, someone might decide to use
it.
;>
Long or short neither bother me unless it is intentionally obnoxious
or undocumented at least somewhere in the file.

Re: Long names are doom ?

[Larry Elmore]

John wrote:
> 
> If there were standard abbreviations or popular abbreviations or
> common ones, I think people would understand those. One way to get a
> happy medium is to use
> Descriptive class names or somewhere in the code where you can figure
> out what
> the object is.

Documentation strings are a nice feature of Lisp (_if_ they are used).
 
Larry

Re: Long names are doom ?

[Everett M. Greene]

Patricia Shanahan <pats@acm.org> writes:
> 
> 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.

Re: Long names are doom ?

[AG]

"Patricia Shanahan" <pats@acm.org> wrote in message
news:3B0DD011.88FCD00E@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 :)

Re: Long names are doom ?

[Shankar Unni]

AG wrote:

> 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.

Re: Long names are doom ?

[Gary Scott]

Hi,

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.



Shankar Unni wrote:
> 
> AG wrote:
> 
> > 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
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Long names are doom ?

[Jon Skeet]

Gary Scott <scottg@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.)

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Gary Scott]

Jon Skeet wrote:
> 
> Gary Scott <scottg@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 - skeet@pobox.com
> http://www.pobox.com/~skeet
> If replying to the group, please don't mail me at the same time


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Long names are doom ?

[Roedy Green]

On Sun, 27 May 2001 14:02:17 -0500, Gary Scott <scottg@flash.net>
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.

Re: Long names are doom ?

[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

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Chris Smith]

"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote ...
> 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

Re: Long names are doom ?

[Alvaro Segura]

Chris Smith wrote:
 
> 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).

Re: Long names are doom ?

[Rev. Bob 'Bob' Crispen]

The kindly Rev. overheard Alvaro Segura <asegura@facilnet.es> saying
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."

Re: Long names are doom ?

[Marco Schmidt]

On Fri, 01 Jun 2001 13:50:22 -0000, revbob@the.rectory (Rev. Bob 'Bob'
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

Re: Long names are doom ?

[Marin David Condic]

Using plurals for type names and singulars for object names can work - but
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Rev. Bob 'Bob' Crispen" <revbob@the.rectory> wrote in message
news:Xns90B35A5F54A70revbob@207.126.101.100...
>
> 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."

Re: Long names are doom ?

[Roedy Green]

On Fri, 1 Jun 2001 11:09:30 -0400, "Marin David Condic"
<marin.condic.auntie.spam@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.



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.

Re: Long names are doom ?

[Marin David Condic]

Nope. Not a Java programmer. I'm at present a C/C++ Programmer-Under-Duress.
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:ttofhtk7j7ufbtot7l2o0svn71qq0j7420@4ax.com...
>
> 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.
>
>
>
> 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.

Re: Long names are doom ?

[Pete Thompson]

On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
<marin.condic.auntie.spam@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... 

Re: Long names are doom ?

[AG]

"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com...
> On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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...

Re: Long names are doom ?

[Pete Thompson]

On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:

Youch.  I lost the thread a couple of days ago, and only managed to find it
just now.  I didn't realize that my post had sparked a bit of a sub-thread
there  :)  In any case, I'll try to address most responses in this single
post...

>> 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:)

Yes, of course having a code convention is important in a team.  What I was
trying to get at was that if your standards are different from the
"conventional" standard for the language you're using, then perhaps it's your
own standards that needs to be looked at.  Of course, I'm no Ada programmer, so
I don't know what the standards are like in Ada.

But suffice to say that it would seem that the standards for Ada and C/C++ seem
to be different.  :/

>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 ...

No, that's not what I was saying at all.  I'll try to explain better:

In most C/C++ code, I very rarely ever see anyone using an underscore in a
variable name.  When they do, they usually come from a Pascal background.

It's fairly standard for C/C++ (and Java it would seem) to simply capitalize
each word in a variable name (with the exception of the first word).  When
you're writing C/C++ code, your target audience is generally other C/C++
programmers who already follows the same (or similar) conventions.  Underscores
then become less needed. 

>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.

I'm a touch-typist.  I've been a touch-typist for longer than I'd care to think
about <G>, and therein lies the problem, actually.  My right hand's beginning
to feel the strain.  

You're right, medical issues have nothing to do with programming, but it *IS*
an issue, and it's growing bigger in the marketplace every day.  And it just so
happens that it's an issue that affects typing. 


>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?

re:  This_Is_A_Variable.

Those "3 characters" can quickly expand when you actually use that variable
name in a block of code (or more if it's a major variable name in an entire
program).  Plus you'd be using it in all the other variable names and function
names.  So we're not talking about only 3 characters.

>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?

No, that is not my contention at all.  See above.

It's a bit unfair to compare the underscore to the spacebar.  The spacebar is
essential to separate keywords.  The underscore is not.  It's purely used for
readability issues.

>>  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...

Yep.  Want a better example?  Try hungarian notation.

char* pszString;

It looks weird.  It looks clumsy.  And it stops typecasting errors cold once
you get the hang of it, and learn how to read it naturally.

The bottom line is that when you've been using a language for a long time, then
its conventions become second-nature to you.  It's a bit like a culture shock
when talking to programmers of other languages.

Just curious... but do you use perl?

Re: Long names are doom ?

[Chris Uzdavinis]

Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:

> On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:

> In most C/C++ code, I very rarely ever see anyone using an
> underscore in a variable name.  When they do, they usually come from
> a Pascal background.

Sorry, I must disagree with your generalization.  Using underscores
has strong C++ roots -- their use is common in the C++ standard
itself. 

Most names in the C++ Standard library uses underscores as separators
when one is needed (random_shuffle, const_iterator, next_permutation,
type_name, etc.)  Even keywords in C++ use underscores: dynamic_cast,
const_cast, static_cast, reinterpret_cast, wchar_t.

The GNU coding standard uses underscores in identifiers.  (For that
matter, The Linux kernel itself is coded using underscore notation.)
Plus, every platform-specific extension by any C++ compiler vendor is
required to have leading underscores (__declspec, __finally, __int64,
etc), and all implementations of the standard library internally use
leading underscores, since the standard explicitly reserves such names
(in global scope) for their use.

It's common among Unix programmers to use trailing underscores on
variable names to indicate class membership.  In windows, it's common
to prefix member variables with m_ to indicate class membership.

-- 
Chris

Re: Long names are doom ?

[Pete Thompson]

On 05 Jun 2001 18:22:30 -0400, Chris Uzdavinis <chris@atdesk.com> wrote:

>Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
>
>> On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:
>
>> In most C/C++ code, I very rarely ever see anyone using an
>> underscore in a variable name.  When they do, they usually come from
>> a Pascal background.
>
>Sorry, I must disagree with your generalization.  Using underscores
>has strong C++ roots -- their use is common in the C++ standard
>itself. 
>
>Most names in the C++ Standard library uses underscores as separators
>when one is needed (random_shuffle, const_iterator, next_permutation,
>type_name, etc.)  Even keywords in C++ use underscores: dynamic_cast,
>const_cast, static_cast, reinterpret_cast, wchar_t.
>
>The GNU coding standard uses underscores in identifiers.  (For that
>matter, The Linux kernel itself is coded using underscore notation.)
>Plus, every platform-specific extension by any C++ compiler vendor is
>required to have leading underscores (__declspec, __finally, __int64,
>etc), and all implementations of the standard library internally use
>leading underscores, since the standard explicitly reserves such names
>(in global scope) for their use.
>
>It's common among Unix programmers to use trailing underscores on
>variable names to indicate class membership.  In windows, it's common
>to prefix member variables with m_ to indicate class membership.

Sure, underscores are used quite heavily in header files, macros, and in
argument parameters.  However, I'm referring to general variable names and
function names, where the underscore is used as a separator between words
within a variable/function name.

Underscores were used heavily in the past, I'll give you that, but I suspect it
was mostly because programmers had migrated to C/C++ from other languages where
the underscore was quite prominent.

In today's times, I rarely see people using it in their variable and function
names, and even then, only to indicate a prefix/suffix like your class member
example.  Not as a separator of words within a variable name.

I suspect if the C/C++ language was to be re-created from scratch today, the
underscore would be more omitted.  As it is now, we have quite an inconsistency
within the language:  typedef, sizeof, dynamic_cast, size_t, memset, iostream
classes and methods, etc.

Re: Long names are doom ?

[John English]

Pete Thompson wrote:
> Underscores were used heavily in the past, I'll give you that, but I suspect it
> was mostly because programmers had migrated to C/C++ from other languages where
> the underscore was quite prominent.

I think you'll find that C code of 20 or 30 years ago (K&R C, long before
ANSI C let alone C++) traditionally used lower_case_with_underlines for
identifiers, and the fashion for namesWithCapitalLetters is a more recent
one... Certainly there are no capital letters used in the standard libraries
other than in #defines, and then they're ALL_CAPS_WITH_UNDERLINES.

IIRC the first language where I found namesLikeThis in common usage
was Smalltalk.

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Larry Elmore]

John English wrote:
> 
> Pete Thompson wrote:
> > Underscores were used heavily in the past, I'll give you that, but I suspect it
> > was mostly because programmers had migrated to C/C++ from other languages where
> > the underscore was quite prominent.
> 
> I think you'll find that C code of 20 or 30 years ago (K&R C, long before
> ANSI C let alone C++) traditionally used lower_case_with_underlines for
> identifiers, and the fashion for namesWithCapitalLetters is a more recent
> one... Certainly there are no capital letters used in the standard libraries
> other than in #defines, and then they're ALL_CAPS_WITH_UNDERLINES.
> 
> IIRC the first language where I found namesLikeThis in common usage
> was Smalltalk.

I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
if Pascal adopted it from something earlier.

Larry

Re: Long names are doom ?

[Wes Groleau]

> > IIRC the first language where I found namesLikeThis in common usage
> > was Smalltalk.
> 
> I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> if Pascal adopted it from something earlier.

I wrote thousands of lines of Pascal without ever doing that
or even seeing it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Larry Elmore]

Wes Groleau wrote:
> 
> > > IIRC the first language where I found namesLikeThis in common usage
> > > was Smalltalk.
> >
> > I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> > if Pascal adopted it from something earlier.
> 
> I wrote thousands of lines of Pascal without ever doing that
> or even seeing it.

Curious. I learned Pascal in 1984 (Montana State used it then, now they
use Ada for 2 years and C++ thereafter (ick)). I've only rarely seen
Pascal written any other way. The three books on my shelf that have
Pascal code in them have namesLikeThis, and I know Delphi's Object
Pascal has always been written in that style.

Larry

Re: Long names are doom ?

[Patricia Shanahan]

Larry Elmore wrote:
> 
> Wes Groleau wrote:
> >
> > > > IIRC the first language where I found namesLikeThis in common usage
> > > > was Smalltalk.
> > >
> > > I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> > > if Pascal adopted it from something earlier.
> >
> > I wrote thousands of lines of Pascal without ever doing that
> > or even seeing it.
> 
> Curious. I learned Pascal in 1984 (Montana State used it then, now they
> use Ada for 2 years and C++ thereafter (ick)). I've only rarely seen
> Pascal written any other way. The three books on my shelf that have
> Pascal code in them have namesLikeThis, and I know Delphi's Object
> Pascal has always been written in that style.
> 
> Larry

Since I rarely throw away books, I still have the copy of the "Pascal
User Manual and Report" (2nd. Edition, Kathleen Jensen and Niklaus
Wirth, 1974) from which I learned Pascal. It uses all lower case
identifiers, with no punctuation to separate words, or more commonly
their abbreviations.

Flipping through it, I just came across "egrepeat" which had me
wondering for a moment why a sample program would do anything with peat,
and what does "egre" mean anyway?

Patricia

Re: Long names are doom ?

[Adam Beneschan]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote in message news:<3B210FF5.C53AC949@ftw.rsc.raytheon.com>...
> > > IIRC the first language where I found namesLikeThis in common usage
> > > was Smalltalk.
> > 
> > I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> > if Pascal adopted it from something earlier.
> 
> I wrote thousands of lines of Pascal without ever doing that
> or even seeing it.

Actually, when I worked with Pascal in college (late 70's-early 80's), we
were encouraged to use the "pseudo-germanic" style, and our lab director gave
some examples of why.  Before that, the tendency was to use all capitals with
no underscores (which aren't or weren't part of Pascal).  So if you had a 
variable named "Go On", it would look funny in all capitals with no separators.
But the worst example . . .

We were using UCSD Pascal, which had a simple graphics package called
TURTLEGRAPHICS.  The concept was simple.  The package had a "pen" that you could
move around.  The pen could be either up or down.  While it was down, a line
would get drawn on the screen when you moved the pen from one location to
another.  While it was up, you could move the pen without drawing anything.

Anyway, the all-capitals-with-no-separators practice caused some problems 
when programmers were using Turtlegraphics and they wanted a Boolean variable
to hold the current state of the pen, naturally called "Pen Is Down" . . .

Just reminiscing . . .
				-- Adam

Re: Long names are doom ?

[James Kanze]

John English wrote:

> Pete Thompson wrote:
> > Underscores were used heavily in the past, I'll give you that, but
> > I suspect it was mostly because programmers had migrated to C/C++
> > from other languages where the underscore was quite prominent.

> I think you'll find that C code of 20 or 30 years ago (K&R C, long
> before ANSI C let alone C++) traditionally used
> lower_case_with_underlines for identifiers, 

C code of 20 or 30 years ago didn't use either. Identifiers would be
something like lwrcswuline.  Modern C++ makes extensive use of the _
as a separator, at least in the standard libraries.  Ten years ago,
however, it was still more or less following the C tradition.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[John English]

James Kanze wrote:
> 
> John English wrote:
> > I think you'll find that C code of 20 or 30 years ago (K&R C, long
> > before ANSI C let alone C++) traditionally used
> > lower_case_with_underlines for identifiers,
> 
> C code of 20 or 30 years ago didn't use either. Identifiers would be
> something like lwrcswuline.  Modern C++ makes extensive use of the _
> as a separator, at least in the standard libraries.  Ten years ago,
> however, it was still more or less following the C tradition.

Well, *I* used to use underlines in *my* C code in the 70s/80s... :-)

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Chris Uzdavinis]

John English <je@brighton.ac.uk> writes:

> James Kanze wrote:
> > 
> > C code of 20 or 30 years ago didn't use either. Identifiers would be
> > something like lwrcswuline.  Modern C++ makes extensive use of the _
> > as a separator, at least in the standard libraries.  Ten years ago,
> > however, it was still more or less following the C tradition.
> 
> Well, *I* used to use underlines in *my* C code in the 70s/80s... :-)

You were ahead of your time.  :)

-- 
Chris

Re: Long names are doom ?

[James Kanze]

Pete Thompson wrote:

> In most C/C++ code, I very rarely ever see anyone using an
> underscore in a variable name.  When they do, they usually come from
> a Pascal background.

I don't think that the people who thought up size_t necessarily come
from a Pascal background.

> It's fairly standard for C/C++ (and Java it would seem) to simply
> capitalize each word in a variable name (with the exception of the
> first word).  When you're writing C/C++ code, your target audience
> is generally other C/C++ programmers who already follows the same
> (or similar) conventions.  Underscores then become less needed.

I've only rarely seen this convention in C/C++ outside of the telecoms
domain (where the convention corresponds to the naming convention in
the telecoms standards).

The most frequent convention in C/C++ seems to be to not signal the
start of a new word at all, and to abbreviate to a point that no one
can recognize words anyway:-).  (getenv, chmod, etc.)  When the start
of words is marked, it is with a _; just look at the C++ standard
library.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Simon Wright]

Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:

> On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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.

Re: Long names are doom ?

[Ted Dennison]

In article <aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com>, Pete Thompson says...
>
>...  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.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

Its important to note that the actual act of *typing* the code is so trivial
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:IsNS6.3800$v4.180713@www.newsranger.com...
> In article <aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com>, Pete Thompson
says...
> >
> >...  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.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Roedy Green]

On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@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.



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.

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> 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              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <pb2ohtgs64jhssmmohpq5qr7nmcsq6119c@4ax.com>, Roedy Green says...
>
>On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
><marin.condic.auntie.spam@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.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 13:25:58 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>>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?

Not at all.  By terse I mean bubblegum-free, not abbreviated. 

However, APL does have ways of avoiding the bubblegum of dealing with
subscripts and manually tracking just how many elements are in the
array.  It takes those details out of your concern and lets you focus
on the problem.

People are stupid and have great difficulty with information overload.
Anything the computer can do for itself, should be taken out of
applications.

It very difficult to appreciate the value of this if you have never
programmed any other way other than buried in bubblegum.



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.

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 13:25:58 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :


>So by this rule, APL produces the most readable code?

APL has a bit of a bum rap for several reasons:

1. the glyphs were unreadable on the screens and golf ball typewriters
of the time. Iverson designed the glyphs only to be typeset. They are
not nearly distinct enough for low res.

2. people judged the language on its IMMEDIATE readability, not after
some practice so that the operators were familiar.

3. APL programmers, like Forth programmers, liked to show off with
tricky opaque but terse code.

But in general, if a solution is shorter, there is less to digest.
There is less to go wrong. There is less to keep in sync.

Creating terseness with meaningless short identifiers is not what I
meant.  Terseness by needing the fewest number of syntatic elements
with the greatest simplicity in their connections, is valid.

Redundancy, just as in English, can help reduce errors. I 
exaggerate slightly, but, in PostScript for example, almost any string
of characters you get from a monkey on a typewriter can be fed
successfully to a PS parser.  Achieving your terseness at that expense
is not wise.




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.

Re: Long names are doom ?

[Ted Dennison]

In article <7ciqhtk6595rgr8qsc92d793ubl1l47saj@4ax.com>, Roedy Green says...
>
>On Tue, 05 Jun 2001 13:25:58 GMT, Ted Dennison<dennison@telepath.com>
>wrote or quoted :
>Creating terseness with meaningless short identifiers is not what I

There are some circumstances where non-identifier based terseness hurts. For
example, its quite possible in C to make many short "if" statements much more
terse using the "?" operator. Its also quite possible to "tersify" many loops by
putting *all* their code inside the parentheses of a "for" loop (the comma
operator helps here). This may be physically shorter, but most C programmers I
know would not consider it easier to understand. Both of these techniques are
outlawed in many C programming standards.

>meant.  Terseness by needing the fewest number of syntatic elements
>with the greatest simplicity in their connections, is valid.

OK. I can agree with that. But I think you are talking about *complexity*, not
tersenes. They may often go hand-in-hand, but there's a *big* difference.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Wes Groleau]

> exaggerate slightly, but, in PostScript for example, almost any string
> of characters you get from a monkey on a typewriter can be fed
> successfully to a PS parser.  Achieving your terseness at that expense
> is not wise.

Change Postscript to C and it's less of an exaggeration.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Marin David Condic]

Mostly because with C, the compiler takes the attitude of "I don't care if
it wrong - I'll close my eyes, ignore it, generate code anyway and you can
go find the problem with the debugger!" :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B1E33AF.CB1AB79D@ftw.rsc.raytheon.com...
>
> > exaggerate slightly, but, in PostScript for example, almost any string
> > of characters you get from a monkey on a typewriter can be fed
> > successfully to a PS parser.  Achieving your terseness at that expense
> > is not wise.
>
> Change Postscript to C and it's less of an exaggeration.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Roedy Green]

On Wed, 06 Jun 2001 08:44:15 -0500, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote or quoted :

>Change Postscript to C and it's less of an exaggeration.

C at least makes you declare your identifiers which catches many typos
at compile time.

Fortran's habit of gleefully creating a new variable when you
misspelled an existing one lead to all kinds of problems, especially
in the days when keypunch operators would literally type 0 for O or O
for 0 if you left off the / in your hand written document.

There was one keypunchist, Loreli, beloved of all the Fortran
programmers, who would hand you your deck back with, set of extra
cards attached with what she thought you REALLY meant. In the days
when you got one compile a day, that made a big difference.

I am a very big fan of languages where you must define everything you
use, and put as much information about how to handle that thing, in
one place, in the definition. 

Java, with its casts, want you to specify the type information all
over the procedural code. It also wants you handle the formatting for
display procedurally.  It also wants you to handle data validation
procedurally. This leads to inevitable inconsistency.


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.

Re: Long names are doom ?

[Gary Scott]

It's true that Fortran still allows implicit declarations.  But it also
allows you to turn it off, which 99% do.  It is unfortunate that that
behavior is not the default for free-form source.  It was fully
unnecessary for free-form source applications to maintain backward
compatibility with that particular feature.

Roedy Green wrote:
> 
> On Wed, 06 Jun 2001 08:44:15 -0500, Wes Groleau
> <wwgrol@ftw.rsc.raytheon.com> wrote or quoted :
> 
> >Change Postscript to C and it's less of an exaggeration.
> 
> C at least makes you declare your identifiers which catches many typos
> at compile time.
> 
> Fortran's habit of gleefully creating a new variable when you
> misspelled an existing one lead to all kinds of problems, especially
> in the days when keypunch operators would literally type 0 for O or O
> for 0 if you left off the / in your hand written document.
> 
> There was one keypunchist, Loreli, beloved of all the Fortran
> programmers, who would hand you your deck back with, set of extra
> cards attached with what she thought you REALLY meant. In the days
> when you got one compile a day, that made a big difference.
> 
> I am a very big fan of languages where you must define everything you
> use, and put as much information about how to handle that thing, in
> one place, in the definition.
> 
> Java, with its casts, want you to specify the type information all
> over the procedural code. It also wants you handle the formatting for
> display procedurally.  It also wants you to handle data validation
> procedurally. This leads to inevitable inconsistency.
> 
> 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.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <7ciqhtk6595rgr8qsc92d793ubl1l47saj@4ax.com>, on 06/05/2001
   at 09:15 PM, Roedy Green <roedy@mindprod.com> said:

>APL has a bit of a bum rap for several reasons:

And for some good reasons:

No operator precedence

Fixed[1] array lower bounds

Poor character handling. But C suffers from the same disease

Little attention to program structure

Reliance on "magic numbers"

[1] FSVO fixed. They can be 0 or 1, on an all-or-nothing basis.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[James Kanze]

"Shmuel (Seymour J.) Metz" wrote:

>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I

Do you drive an Edsel, too?

(Sorry, I couldn't resist:-).  But PL/I and OS/2 both...)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Gary Scott]

Hey!...we still have hundreds of jobs using Jovial (openings too)...

James Kanze wrote:
> 
> "Shmuel (Seymour J.) Metz" wrote:
> 
> >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> >      Atid/2
> >      Team OS/2
> >      Team PL/I
> 
> Do you drive an Edsel, too?
> 
> (Sorry, I couldn't resist:-).  But PL/I and OS/2 both...)
> 
> --
> James Kanze                               mailto:kanze@gabi-soft.de
> Conseils en informatique orient�e objet/
>                    Beratung in objektorientierter Datenverarbeitung
> Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B20D2D8.4AD88183@dresdner-bank.com>, on 06/08/2001
   at 03:27 PM, James Kanze <James.Kanze@dresdner-bank.com> said:

>Do you drive an Edsel, too?

Well, if at the time[1] the Edsel was being marketed the alternative
was a Renault, then I would have driven an Edsel. Is there some reason
that I should run a popular broken system instead of an unpopular
working system that suits my needs?

[1] Ignoring issues like legal driving age.

-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Dirk Bosmans]

I'm responding to following parts of Roedy Green <roedy@mindprod.com>'s article
in comp.lang.java.programmer on Mon, 04 Jun 2001 22:26:20 GMT6

>On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
><marin.condic.auntie.spam@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.  

Do you mean the way they are highlighted in Excell formules? Wonderfull, isn't
it. On each IDE review I write I mention this in the TODO list.

>
>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.
>
>
>
>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.


Greetings,
Dirk Bosmans


Java tools at http://users.belgacombusiness.net/arci/
- Cramfull Resource Compiler library (NEW)
- Applicet Framework: turns Applets into Applications
- ArciMath BigDecimal: now with BigDecimalFormat

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 21:44:31 +0200, Dirk Bosmans
<Dirk.Bosmans@tijd.com> wrote or quoted :

>Do you mean the way they are highlighted in Excell formules? Wonderfull, isn't
>it. On each IDE review I write I mention this in the TODO list

It is exciting when Microsoft adopts radical new ideas like this, I
mean as in Sir Isaac Newton's mathematical notation or Knuth's TeX for
something a little more recent.

I wonder when the 2D graphic nature of the screen will dawn on the
authors of Java IDEs.  I think they fear future shock if they
attempted it. We Java programmers are such old fogies glued to our
glass TTY metaphor.

see http://mindprod.com/scid.html



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.

Re: Long names are doom ?

[James Kanze]

Roedy Green wrote:

> I wonder when the 2D graphic nature of the screen will dawn on the
> authors of Java IDEs.  I think they fear future shock if they
> attempted it. We Java programmers are such old fogies glued to our
> glass TTY metaphor.

It's the C heritage.  (And the TTY isn't glass.  It makes a real bang
each time a character is output.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B20D334.309E06DD@dresdner-bank.com>, on 06/08/2001
   at 03:29 PM, James Kanze <James.Kanze@dresdner-bank.com> said:

>It's the C heritage.  (And the TTY isn't glass.  It makes a real bang
>each time a character is output.)

TTY is an abbreviation for Teletype. It refers to more than just,
e.g., an ASR33. Some Teletype products used a CRT. Q.E.D.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Roedy Green]

On Wed, 13 Jun 2001 08:33:53 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote or quoted :

>TTY isn't glass
 
"glass TTY" is Canadian for a dumb terminal, most notably the VU-Com
then the more flexible DEC VT-100.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Jerry Petrey]

Roedy Green wrote:
> 
> On Wed, 13 Jun 2001 08:33:53 -0400, "Shmuel (Seymour J.) Metz"
> <spamtrap@library.lspace.org.invalid> wrote or quoted :
> 
> >TTY isn't glass
> 
> "glass TTY" is Canadian for a dumb terminal, most notably the VU-Com
> then the more flexible DEC VT-100.
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Not just Canadian -
'Glass TTY' has been in common use in the US for many years for the
same thing (a dumb terminal).


Jerry
-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <hljfitke5uvgn1nj3vadlt5hjrghruholn@4ax.com>, on 06/13/2001
   at 08:38 PM, Roedy Green <roedy@mindprod.com> said:

>On Wed, 13 Jun 2001 08:33:53 -0400, "Shmuel (Seymour J.) Metz"
><spamtrap@library.lspace.org.invalid> wrote or quoted :

>>TTY isn't glass
> 
>"glass TTY" is Canadian for a dumb terminal, most notably the VU-Com
>then the more flexible DEC VT-100.

TTY is an abbreviation for Teletype and, as I noted, some Teletype
products were CRT terminals. The usage "glass TTY" is by no means
limited to Canada.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Conrad Schneiker]

IMHO, this has strayed pretty far off topic insofar as Ruby is concerned.

Please omit comp.lang.ruby from future replies to this thread.

Perhaps mercy and/or a little more netiquitte for other newsgroups is called
for as well. :-)

Thanks.

Conrad

Re: Long names are doom ?

[Larry Kilgallen]

In article <pb2ohtgs64jhssmmohpq5qr7nmcsq6119c@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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

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.

Re: Long names are doom ?

[Roedy Green]

On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
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.



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.

Re: Long names are doom ?

[Roedy Green]

On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
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.



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.

Re: Long names are doom ?

[Blaikie]

> 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.

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

Re: Long names are doom ?

[Gary Scott]

Kedit matches left/right by color.  No def file for Ada, but you could
easily write one.

Roedy Green wrote:
> 
> On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> 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.
> 
> 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.

Re: Long names are doom ?

[Larry Kilgallen]

In article <bqeoht05rusrp4v72bf2aq4r0ib4s5c5fs@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> 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.

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".

Re: Long names are doom ?

[Roedy Green]

On 4 Jun 2001 22:27:23 -0500, Kilgallen@eisner.decus.org.nospam (Larry
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.


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.

Re: Long names are doom ?

[Blaikie]

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
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

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> 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
> 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)

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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[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)
> It doesn't always work like that, but it can. Code repetition isn't the
> 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

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> 
> > > 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)
> > It doesn't always work like that, but it can. Code repetition isn't the
> > 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

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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> 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.

quite probably, neways the point is, we agree, its just a matter of degrees
and probability of atomic code
db

Re: Long names are doom ?

[Ted Dennison]

In article <9fi87m$9du$1@bugstomper.ihug.com.au>, Blaikie says...
>
>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.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> 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...

I beg to differ.

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

If you like maintainability - you probably want to look seriously at Ada.
That was one of the design goals of the language. There are lots of examples
on the net of well structured Ada code that I believe illustrate how it can
be used to develop more easily maintained systems. (I like to think the code
on my web page is very readable & maintainable. Take a look at some of it
at: http://www.mcondic.com/ There are plenty of other examples & a good
place to start is at http://www.adapower.org/)

I'd have to disagree on the notion that "terseness" in and of itself is
somehow going to contribute to clarity & maintainability. In my experience,
what counts much more is clarity of thought in the original design, a
logical breakdown of the problem into pieces, meaningful expression of the
design in the language of implementation (good names, comments, obvious
flow, etc.) and support from the environment for error detection and
correction. If expressing something in as few keystrokes as possible were
somehow going to lead to maintainability, then the answer would have been
things like APL - or even machine code. (Not many characters needed to
represent hex digits, right?)

If "terseness" is really another word for "abstraction" then I might be
inclined to agree. Saying in your code something like: Quick_Sort
(Some_Array) ; is obviously easier to understand than spelling out in great
detail the entire Quick Sort algorithm. Here the "terseness" is a way of
saying "There is this highly complex operation of sorting an array that you
don't need to bother trying to understand. Trust me. When I get back from
the call, your whole array will be sorted." That sort of "terseness" I'd
concede helps with maintenance - but I think it is more aptly named
"Abstraction" or "Functional Independence".

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:q81pht43ib89sjop0i245bvs502416t1tp@4ax.com...
> On 4 Jun 2001 22:27:23 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> 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.
>
>
> 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.

Re: Long names are doom ?

[Larry Kilgallen]

In article <MPG.1586b84f5bc22ee798a6c8@mrmog.peramon.com>, Jon Skeet <skeet@pobox.com> writes:
> Blaikie <david_blaikie@hotmail.com> wrote:
>> 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
>> 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)
> 
> 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.

For me, block comments do that just as well as subprograms.

Re: Long names are doom ?

[Larry Kilgallen]

In article <MPG.1586bd4148c0f02198a6ca@mrmog.peramon.com>, Jon Skeet <skeet@pobox.com> writes:
> Blaikie <david_blaikie@hotmail.com> wrote:
>> 
>> > > 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)
>> > It doesn't always work like that, but it can. Code repetition isn't the
>> > 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
> 
> 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.

How about a case statement for 137 possible cases ?

Even if it only calls a separate subprogram for each, that is longer
than most people's screenful.

Re: Long names are doom ?

[Jon Skeet]

Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:

> > I'd suggest that *very* few methods which are ten pages of code which 
> > *can't* be broken down further are well-designed.
> 
> How about a case statement for 137 possible cases ?
> 
> Even if it only calls a separate subprogram for each, that is longer
> than most people's screenful.

Yup - and how often does that happen (in a way which isn't better coped 
with by more object-oriented design)?

Very occasionally - hence my allowance that it's possible. I suspect 
there are far more programs with methods of 10 "normal" screenfuls that 
are just badly written than there are programs with a genuine 
justification for it.

(Note - I'm discounting auto-generated code in the above; that will 
often naturally create huge methods.)

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Steve Bellenot]

In article <+FWVg+noA0yk@eisner.encompasserve.org>,
Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
>In article <MPG.1586bd4148c0f02198a6ca@mrmog.peramon.com>, Jon Skeet <skeet@pobox.com> writes:
>> Blaikie <david_blaikie@hotmail.com> wrote:
>>> 
>>> > > 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)
>>> > It doesn't always work like that, but it can. Code repetition isn't the
>>> > 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
>> 
>> 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.
>
>How about a case statement for 137 possible cases ?

Depends on the language of course, but I think it is likely that this
is the wrong solution. At some point, it would make sense to replace
the case statement with a config file and some program that automatically
generated the case code from the config file. 

If the language supported it, a jump table might make more sense than
a case statement. Again the jump table could be loaded from a config
file.

>Even if it only calls a separate subprogram for each, that is longer
>than most people's screenful.

-- 
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu 
+1.850.644.7189 (4053fax)

Re: Long names are doom ?

[Blaikie]

> Depends on the language of course, but I think it is likely that this
> is the wrong solution. At some point, it would make sense to replace
> the case statement with a config file and some program that automatically
> generated the case code from the config file.
>
> If the language supported it, a jump table might make more sense than
> a case statement. Again the jump table could be loaded from a config
> file.

well i am not sure what a jump table is, but if it were in Java and there
were corresponding methods to each of the cases in the swtich, i would use a
general piece of java.lang.reflection code to load the method based directly
on the string (or turn the variable into the string nescessary using maybe a
hashmap)
db

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> > Depends on the language of course, but I think it is likely that this
> > is the wrong solution. At some point, it would make sense to replace
> > the case statement with a config file and some program that automatically
> > generated the case code from the config file.
> >
> > If the language supported it, a jump table might make more sense than
> > a case statement. Again the jump table could be loaded from a config
> > file.
> 
> well i am not sure what a jump table is, but if it were in Java and there
> were corresponding methods to each of the cases in the swtich, i would use a
> general piece of java.lang.reflection code to load the method based directly
> on the string (or turn the variable into the string nescessary using maybe a
> hashmap)

Reflection would be an *incredibly* slow way of doing that. Better would 
be to create (at startup) one object for handling each case, each 
implementing the same interface. Put *those* into a map of some 
description, then get out the "right" object and call one of the methods 
of the common interface.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> Reflection would be an *incredibly* slow way of doing that. Better would
> be to create (at startup) one object for handling each case, each
> implementing the same interface. Put *those* into a map of some
> description, then get out the "right" object and call one of the methods
> of the common interface.

what makes u say reflection is so slow? seems alot of applications use it
alot (main one i can think of is jsp)
db

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> > Reflection would be an *incredibly* slow way of doing that. Better would
> > be to create (at startup) one object for handling each case, each
> > implementing the same interface. Put *those* into a map of some
> > description, then get out the "right" object and call one of the methods
> > of the common interface.
> 
> what makes u say reflection is so slow? seems alot of applications use it
> alot (main one i can think of is jsp)

Reflection is *far* slower than straight method calls, partly because 
there's an awful lot more to do.

Yes, it's very useful *in its place*, but there's no need to do it in 
this case, and could easily turn it into a bottleneck if this code is 
run frequently.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> Reflection is *far* slower than straight method calls, partly because
> there's an awful lot more to do.

i'm not saying it isn't, but what evidence do u have to suggest it is? if
there is documentation somewhere, i would just like to see it thats all
db

Re: Long names are doom ?

[Roedy Green]

On Wed, 6 Jun 2001 18:18:29 +1000, "Blaikie"
<david_blaikie@hotmail.com> wrote or quoted :

>what makes u say reflection is so slow?
 
Ask Jonathan Revusky about that, then watch the steam shoot from his
ears.  He unsuccessfully tried to convince our boss from using
reflection in a project we both once worked on.  Reflection is a fun
toy, suitable for bean boxes and the like where, but there are much
faster ways of handling the usual production cases.



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.

Re: Long names are doom ?

[Jonathan Revusky]

Roedy Green <roedy@mindprod.com> wrote in message news:<nh6thtgkds4dlubj0s1ss0n7b43jjir39h@4ax.com>...

> On Wed, 6 Jun 2001 18:18:29 +1000, "Blaikie"

> <david_blaikie@hotmail.com> wrote or quoted :

> 

> >what makes u say reflection is so slow?

>  

> Ask Jonathan Revusky about that, then watch the steam shoot from his

> ears.  He unsuccessfully tried to convince our boss from using

> reflection in a project we both once worked on.  Reflection is a fun

> toy, suitable for bean boxes and the like where, but there are much

> faster ways of handling the usual production cases.


I didn't actually care so much about calls via reflection being slower
(though I guess they must be and it is also something to worry
about... a bit) but my concern was the tendency for the code to be
very difficult to read or maintain.

I think there is a tendency for the C hackers moving to Java to
overuse reflection (once they discover it) because things like
java.lang.reflect.Method can map perfectly in their minds to a C
function pointer. Also, the C hackers aren't usually familiar enough
with OO patterns to realize that you don't really need function
pointers like that in Java. (Or at least hardly ever.) In C, the use
of the function pointers also leads to very obfuscated,
hard-to-maintain code, but that's really unavoidable. AFAICS it's the
only way you get polymorphism in C.

Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper
classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://www.revusky.com/hacks/

Re: Long names are doom ?

[James Kanze]

Jonathan Revusky wrote:

> I didn't actually care so much about calls via reflection being
> slower (though I guess they must be and it is also something to
> worry about... a bit) but my concern was the tendency for the code
> to be very difficult to read or maintain.

Not to mention that it means that all of the compiler type checking is
moved off to runtime.

> I think there is a tendency for the C hackers moving to Java to
> overuse reflection (once they discover it) because things like
> java.lang.reflect.Method can map perfectly in their minds to a C
> function pointer.

Except that most real C hackers don't use function pointers, either.
Most often, I've seen monster switches or a chain of if's.

> Also, the C hackers aren't usually familiar enough with OO patterns
> to realize that you don't really need function pointers like that in
> Java. (Or at least hardly ever.) In C, the use of the function
> pointers also leads to very obfuscated, hard-to-maintain code, but
> that's really unavoidable. AFAICS it's the only way you get
> polymorphism in C.

As with many things, used correctly, function pointers can actually
improve readability.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[James Kanze]

Jon Skeet wrote:

> Blaikie <david_blaikie@hotmail.com> wrote:
> > > Depends on the language of course, but I think it is likely that
> > > this is the wrong solution. At some point, it would make sense
> > > to replace the case statement with a config file and some
> > > program that automatically generated the case code from the
> > > config file.

> > > If the language supported it, a jump table might make more sense
> > > than a case statement. Again the jump table could be loaded from
> > > a config file.

> > well i am not sure what a jump table is, but if it were in Java
> > and there were corresponding methods to each of the cases in the
> > swtich, i would use a general piece of java.lang.reflection code
> > to load the method based directly on the string (or turn the
> > variable into the string nescessary using maybe a hashmap)

> Reflection would be an *incredibly* slow way of doing that. Better
> would be to create (at startup) one object for handling each case,
> each implementing the same interface. Put *those* into a map of some
> description, then get out the "right" object and call one of the
> methods of the common interface.

That's the way I generally do it, but there are exceptions.  The
classical example is in lexical analysis, where you use a switch with
one entry per starting character.  Speed is often an issue here, of
course.  (And in most modern systems, you'll arrange for the switch to
be generated automatically, so it isn't hand written code.)

Of course, the fact that there is ONE exception doesn't invalidate the
general premice.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Larry Kilgallen]

In article <eseohtcf468ea4v1klabbm47k01uohdnt3@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> 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.

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 ) );

Re: Long names are doom ?

[Larry Kilgallen]

In article <bqeoht05rusrp4v72bf2aq4r0ib4s5c5fs@4ax.com>, Roedy Green <roedy@mindprod.com> writes:

> See also http://mindprod.com/unmain.html an essay on how to write
> unmaintainable code.

That is a good essay, though.

Re: Long names are doom ?

[Pete Thompson]

On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

>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

Terse for the sake of readability is good.  It gets right to the point.

Terse for the sake of being cryptic is bad.  

Re: Long names are doom ?

[Marin David Condic]

My comment is WRT "terse" for the sake of "terse". If the goal is
"readability" then it is yet to be demonstrated to my satisfaction that
"terse" serves this goal. As has been noted elsewhere, APL and assembly
language could both be described as "terse" and neither is typically held up
as an example of how to produce "readability". If one would contend that
"terse" serves "readability" I would ask to see some kind of study backing
up that claim - complete with a definition of what counts as "terse" and
what is simply "cryptic".

Granted, there are some shorthand notations within any given language that
the cognosenti immediately recognize. This might lead them to believe that
their shorthand is thus more "readable". What they are really seeing is the
fact that it is their familiarity with the idiom that makes it readable - in
the same way that a program I spend weeks building & massaging is more
"readable" than the one someone just now dumped in my lap.

In my estimation, the issue of "readability" is far more important for
someone *new* to a project and/or *new* to the language. Can they walk in
the door and get up to speed more quickly (thus making more money for the
stockholders) if we rely on "terse" languages/notations or will they become
productive faster if the language/notations are more verbose, rely less on
non-obvious semantics, have better comments, etc.?

As for "terse for the sake of being cryptic" - that's obviously A Bad Thing.
My contention is that some programmers are terse for the sake of being
cryptic without really realizing that this is what they are doing. As
cognosenti they derive satisfaction from having what seems cryptic to the
outsider seem intuitively obvious to them. They may remark "....Well any
*competent* XXX programmer would understand this code at a glance!..." It
makes them feel good that they (and the rest of the in-crowd) must be
"better" than the unwashed masses.

Me? I'd rather write unbelievably uncomplicated, uncryptic, un-terse code
(especially when using C) so that when I have someone less experienced, less
familiar or less gifted coming on to a project, they can pick it up as
absolutely quickly as is possible and have the minimum problems making
changes to the code. Why? A) it makes money for the stockholders. B) It
keeps them from asking me hundreds of questions and using up my day - thus
making more money for the stockholders. C) Its less likely they'll make a
mistake that ends up costing the company lots of money - again maximizing
shareholder value, D) Did I mention that it makes money for the
stockholders? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:rdeqht0fhtvgbpima8jbuolfvrl88n3cc3@4ax.com...
> On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote:
>
> >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
>
> Terse for the sake of readability is good.  It gets right to the point.
>
> Terse for the sake of being cryptic is bad.
>
>

Re: Long names are doom ?

[Pete Thompson]

On Tue, 5 Jun 2001 16:47:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

>My comment is WRT "terse" for the sake of "terse". If the goal is
>"readability" then it is yet to be demonstrated to my satisfaction that
>"terse" serves this goal. As has been noted elsewhere, APL and assembly

Hmm in that case, I should give you my sister's phone number.  She can talk for
well over two hours on the phone before finally getting to the point  :)  

I feel the same way about code:  being verbose is all well and good, but
pointless verbosity can do more harm than good.  It tends to hide the overall
picture as to what the function/application is *really* doing.  It makes the
function look more complicated than it really is.  It leaves you wondering if
you're somehow missing something because there's more to read than is really
necessary.  

As Roedy mentioned in some other message, it's a hard one to pin down since
it's such a subjective matter.  Maybe it's futile to even try.

>language could both be described as "terse" and neither is typically held up
>as an example of how to produce "readability". If one would contend that
>"terse" serves "readability" I would ask to see some kind of study backing
>up that claim - complete with a definition of what counts as "terse" and
>what is simply "cryptic".

Perhaps it'd help by using a thesaurus?  

Good terse:  clear summary, concise, succinct.
Bad terse:  hidden, cryptic, magical.

Good verbosity: descriptive, explanatory.
Bad verbosity:  tedious, rambling, long-winded.

Which one of the following do you prefer:

i = i + 1;

or

i equals i plus one.  

Imagine a whole program written using the latter method.  Would that really be
much fun to read?  Compound statements would be nearly unreadable.

>Granted, there are some shorthand notations within any given language that
>the cognosenti immediately recognize. This might lead them to believe that
>their shorthand is thus more "readable". What they are really seeing is the
>fact that it is their familiarity with the idiom that makes it readable - in
>the same way that a program I spend weeks building & massaging is more
>"readable" than the one someone just now dumped in my lap.

True.  After all, a mathematical formula may seem cryptic to the average
layperson, but it's immediately readable by other mathematicans.  

>In my estimation, the issue of "readability" is far more important for
>someone *new* to a project and/or *new* to the language. Can they walk in
>the door and get up to speed more quickly (thus making more money for the
>stockholders) if we rely on "terse" languages/notations or will they become
>productive faster if the language/notations are more verbose, rely less on
>non-obvious semantics, have better comments, etc.?

Hmm.. I'd have to say that I agree and disagree.  It really depends on what
industry you're in.  If you're in the kind of industry where you're hiring
newbie programmers all the time, then yes, it's important to be as explicit as
possible.  However, there are industries where programmers MUST be experienced
before they're hired.  Does it really make sense to make your code as
newbie-ish as possible for them?  (Again, without being cryptic).  

There has to be a cut-off point where a certain number of knowledge and
experience is required from new programmers, though.  If they don't meet that
requirement, then they shouldn't have been hired in the first place.  After
all, it's not *my* problem if someone doesn't know what a modulus operator is.

>As for "terse for the sake of being cryptic" - that's obviously A Bad Thing.
>My contention is that some programmers are terse for the sake of being
>cryptic without really realizing that this is what they are doing. As
>cognosenti they derive satisfaction from having what seems cryptic to the
>outsider seem intuitively obvious to them. They may remark "....Well any
>*competent* XXX programmer would understand this code at a glance!..." It
>makes them feel good that they (and the rest of the in-crowd) must be
>"better" than the unwashed masses.

Well, that's sort of going to the extreme.  If the syntax is a part of the
language itself, then it should be readable by anyone well versed with the
language.  "i++" is not cryptic since that's a part of the language.  

If it's a "clever" (ab)use of the language, then you may need to reevaluate
what you're doing.   I hate it when people try to cram 4 or 5 or more different
things into the same line.  I just love reading stuff like c = a+++++b.  (not)

My general convention is one or two instructions per line, if possible, and use
generous amounts of whitespaces and brackets.

>Me? I'd rather write unbelievably uncomplicated, uncryptic, un-terse code
>(especially when using C) so that when I have someone less experienced, less
>familiar or less gifted coming on to a project, they can pick it up as
>absolutely quickly as is possible and have the minimum problems making
>changes to the code. Why? A) it makes money for the stockholders. B) It
>keeps them from asking me hundreds of questions and using up my day - thus
>making more money for the stockholders. C) Its less likely they'll make a
>mistake that ends up costing the company lots of money - again maximizing
>shareholder value, D) Did I mention that it makes money for the
>stockholders? :-)
>
>MDC

I guess we're pretty much arguing the same thing at this point.  My own
contention is that there are programmers who are needlessly verbose that the
code looks more complex than it really is.

Of course, coming from a DirectX background, it's possible that I may be a
little biased  :) 

Re: Long names are doom ?

[John English]

Pete Thompson wrote:
> Good terse:  clear summary, concise, succinct.
> Bad terse:  hidden, cryptic, magical.
> 
> Good verbosity: descriptive, explanatory.
> Bad verbosity:  tedious, rambling, long-winded.

There are also many instances of "bad verbose" code where "bad verbose"
translates to "hidden, cryptic, magical", or even just plain stupid.
As an extreme example of this, I cite a past student of mine who
couldn't remember how to determine the length of a string, and resorted
to writing it to a temporary file because he knew how to find the size
of a file... :-(

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 10:14:31 +0100, John English <je@brighton.ac.uk> wrote:

>Pete Thompson wrote:
>> Good terse:  clear summary, concise, succinct.
>> Bad terse:  hidden, cryptic, magical.
>> 
>> Good verbosity: descriptive, explanatory.
>> Bad verbosity:  tedious, rambling, long-winded.
>
>There are also many instances of "bad verbose" code where "bad verbose"
>translates to "hidden, cryptic, magical", or even just plain stupid.
>As an extreme example of this, I cite a past student of mine who
>couldn't remember how to determine the length of a string, and resorted
>to writing it to a temporary file because he knew how to find the size
>of a file... :-(
>


Ouch.  That's pretty sick.

Still, I'd have to give him a couple of points for creativity  :) 

Re: Long names are doom ?

[David Gillon]

Pete Thompson wrote:

> >In my estimation, the issue of "readability" is far more important for
> >someone *new* to a project and/or *new* to the language. Can they walk in
> >the door and get up to speed more quickly (thus making more money for the
> >stockholders) if we rely on "terse" languages/notations or will they become
> >productive faster if the language/notations are more verbose, rely less on
> >non-obvious semantics, have better comments, etc.?
> 
> Hmm.. I'd have to say that I agree and disagree.  It really depends on what
> industry you're in.  If you're in the kind of industry where you're hiring
> newbie programmers all the time, then yes, it's important to be as explicit as
> possible.  However, there are industries where programmers MUST be experienced
> before they're hired.  Does it really make sense to make your code as
> newbie-ish as possible for them?  (Again, without being cryptic).

Explicit, readable coding has value even when being read by the most
experienced of software engineers. Consider the case of a safety
critical system under review by an external auditor prior to
certification. It's vital he be able to review the system in as thorough
a manner as possible in the time available, yet he may be completely new
to your coding standards and practices. The logic of a decision needs to
be clearly laid our for him, not something he needs to delve into the
musty depths of obscure documents for or to seek information on from the
original coder (especially if the original coder is in a substantially
different timezone). Equally, someone may have to fix your code twenty
years down the tracks, when the original coding team and the rationale
behind their decisions may have long since vanished (or walked in front
of a bus...). 

Explicit pays, maybe not now, maybe not directly, but in the end its a
worthwhile investment.


-- 


David Gillon

Re: Long names are doom ?

[Gary Scott]

Hi,

"Readability" can be far better achieved through the proper use of
comments.  While variable names should be "understandable" (you decide
what that means), the implication that
variables/procedure/class/member/etc names must be full english words is
a red herring.  The CODE does not necessarily need to be so obsessively
verbose, the commentary needs to be verbose (or "sufficiently" so).

David Gillon wrote:
> 
> Pete Thompson wrote:
> 
> > >In my estimation, the issue of "readability" is far more important for
> > >someone *new* to a project and/or *new* to the language. Can they walk in
> > >the door and get up to speed more quickly (thus making more money for the
> > >stockholders) if we rely on "terse" languages/notations or will they become
> > >productive faster if the language/notations are more verbose, rely less on
> > >non-obvious semantics, have better comments, etc.?
> >
> > Hmm.. I'd have to say that I agree and disagree.  It really depends on what
> > industry you're in.  If you're in the kind of industry where you're hiring
> > newbie programmers all the time, then yes, it's important to be as explicit as
> > possible.  However, there are industries where programmers MUST be experienced
> > before they're hired.  Does it really make sense to make your code as
> > newbie-ish as possible for them?  (Again, without being cryptic).
> 
> Explicit, readable coding has value even when being read by the most
> experienced of software engineers. Consider the case of a safety
> critical system under review by an external auditor prior to
> certification. It's vital he be able to review the system in as thorough
> a manner as possible in the time available, yet he may be completely new
> to your coding standards and practices. The logic of a decision needs to
> be clearly laid our for him, not something he needs to delve into the
> musty depths of obscure documents for or to seek information on from the
> original coder (especially if the original coder is in a substantially
> different timezone). Equally, someone may have to fix your code twenty
> years down the tracks, when the original coding team and the rationale
> behind their decisions may have long since vanished (or walked in front
> of a bus...).
> 
> Explicit pays, maybe not now, maybe not directly, but in the end its a
> worthwhile investment.
> 
> --
> 
> David Gillon

Re: Long names are doom ?

[Roedy Green]

On Wed, 06 Jun 2001 10:26:11 -0500, Gary Scott
<Gary.L.Scott@lmtas.lmco.com> wrote or quoted :

>While variable names should be "understandable" (you decide
>what that means), the implication that
>variables/procedure/class/member/etc names must be full english words is
>a red herring.  
 
The really important thing is not having two similar variables/methods
whose purposes could be easily confused.  

The problem usually comes from writing a method with a generic name,
then later adding one with a minor variant.  You probably need to
globally rename the first method to make the distinction clear.

Up until recently, most people considered global renaming infeasible.

If we ever gets SCIDS, http://mindprod.com/scid.html,  I think global
renaming will tend to take over from scoping as the preferred way of
avoiding ambiguity, since human brains don't have scoped memory banks.
"i" will still remain the universal loop counter. This is not a human
ambiguity problem.





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.

Re: Long names are doom ?

[John English]

Gary Scott wrote:
> "Readability" can be far better achieved through the proper use of
> comments.  While variable names should be "understandable" (you decide
> what that means), the implication that
> variables/procedure/class/member/etc names must be full english words is
> a red herring.  The CODE does not necessarily need to be so obsessively
> verbose, the commentary needs to be verbose (or "sufficiently" so).

The trouble is with comments is that they aren't checked by the compiler,
are often not maintained properly when the code is, and can therefore be
misleading. I'd much prefer the code to provide the information that
would otherwise go in the comments, and the use of meaningful names
(not necessarily verbose, just meaningful) goes a long way towards
achieving that. That way my "commentary" is checkable by the compiler.

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 12:30:26 +0100, David Gillon <david.gillon@baesystems.com>
wrote:

>Explicit, readable coding has value even when being read by the most
>experienced of software engineers. Consider the case of a safety
>critical system under review by an external auditor prior to
>certification. It's vital he be able to review the system in as thorough
>a manner as possible in the time available, yet he may be completely new
>to your coding standards and practices. The logic of a decision needs to
>be clearly laid our for him, not something he needs to delve into the
>musty depths of obscure documents for or to seek information on from the
>original coder (especially if the original coder is in a substantially
>different timezone). Equally, someone may have to fix your code twenty
>years down the tracks, when the original coding team and the rationale
>behind their decisions may have long since vanished (or walked in front
>of a bus...). 
>
>Explicit pays, maybe not now, maybe not directly, but in the end its a
>worthwhile investment.

Yes, I quite agree.  The point I was trying to make is that there are varying
levels of "explicitness" allowed in different industries.  In your example, a
critical system designed to last years, you'd be crazy to be non-explicit.  

However, if you're working in an industry where speed and optimization is king,
then you sometimes simply don't have a choice and you're forced to write
optimizations that may look cryptic.  However, in such cases you should be sure
to COMMENT it, and explain what it is and how it works.

I think that people misunderstand me on one thing:  I am not at all arguing
against the use of comments.  The code itself doesn't have to read like an
essay if it's well commented. 

However, if I'm using a fairly standard API, then it's not up to me to write
code that also teaches a newbie programmer how the API works.  That's not my
job.  My job is to do my job, and to explain why and how I'm doing my job, not
teach others how to code.  If a newbie programmer has to read my code, then
there are two requirements expected from him/her:  know the language, and
understand the API.  I don't think this is too much to ask from any new
programmers.

Re: Long names are doom ?

[David Gillon]

Pete Thompson wrote:
> it's not up to me to write
> code that also teaches a newbie programmer how the API works.  That's not my
> job.  My job is to do my job, and to explain why and how I'm doing my job, not
> teach others how to code.  If a newbie programmer has to read my code, then
> there are two requirements expected from him/her:  know the language, and
> understand the API.  I don't think this is too much to ask from any new
> programmers.

Got to disagree with this point. I've always thought that training less
experienced engineers what is good practise and what isn't was a
fundamental part of my job. If you do any kind of code review then this
is something you're doing implicitly, whether you're reviewer or
reviewee.

-- 

David Gillon

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B1E1452.BAFAAB7F@baesystems.com>, on 06/06/2001
   at 12:30 PM, David Gillon <david.gillon@baesystems.com> said:

>Explicit pays, maybe not now, maybe not directly, but in the end its
>a worthwhile investment.

"clear" pays; "explicit" may be a booby trap. Your first priority
should be to make the code clear, maintainable and robust. In most
cases that requires getting rid of explicit values in the code and
relegating them to named constants, #define, EQU or whatever the
equivalents are in the language that you are using. NO MAGIC NUMBERS!


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com...
> Hmm in that case, I should give you my sister's phone number.  She can
talk for
> well over two hours on the phone before finally getting to the point  :)
>
Verbosity for the sake of being verbose is as dumb as terseness for the sake
of being terse. Whatever you put on paper needs to say something *useful* to
the reader and do so in a *clear* manner. Verbosity or terseness must be
used to serve some higher goal - not become goals in and of themselves.

> I feel the same way about code:  being verbose is all well and good, but
> pointless verbosity can do more harm than good.  It tends to hide the
overall
> picture as to what the function/application is *really* doing.  It makes
the
> function look more complicated than it really is.  It leaves you wondering
if
> you're somehow missing something because there's more to read than is
really
> necessary.
>
We agree here. I think that again I'd emphasize that it is neither verbosity
nor terseness that makes something clear to the reader. Clarity of thought
and expression are not going to come from either terse or verbose notation.
First the thought has to be clear. Then you have to find a way of expressing
that thought in a manner that will be understood by the audience.


> As Roedy mentioned in some other message, it's a hard one to pin down
since
> it's such a subjective matter.  Maybe it's futile to even try.
>
There is some subjectivity to it, but I would say "not entirely" I think
that the notation in C is entirely too terse and subject to way too much
abuse. Likewise, I think the syntax of Cobol is way too verbose and
needlessly obfuscates with TMI. (Who thinks that "Add Gin To Vermouth Giving
Martini." is somehow a better idea than "Gin := Vermouth + Martini;" ?)

> Which one of the following do you prefer:
>
> i = i + 1;
>
> or
>
> i equals i plus one.
>
I like the first better. But I dislike things like I++ - not so much that
particular one, but all the subtle variations that can take place. It
changes meaning if it is in front or behind - but that only makes a
difference sometimes. It can be mixed with other interesting variations and
things like +=, etc. In the end, the "terseness" possible with this kind of
operator is just plain not worth it. Way too subject to abuse. Way too easy
to misconstrue meaning in complicated cases. Often ambiguous in definition
leading to "implementation dependent", reliant on side effects, Etc. So to
save the few keystrokes needed for "I := I + 1 ;" I give you "I++" and open
the floodgates for the "Betcha can't guess what *this* line does!!!" kind of
coding. Better to be rid of it and insist on the few extra keystrokes needed
for Fortran-ish expressions and avoid all the trouble that will inevitably
come from that programmer who will insist that "It should be intuitively
obvious to any *COMPETENT* C programmer..."

> Imagine a whole program written using the latter method.  Would that
really be
> much fun to read?  Compound statements would be nearly unreadable.
>
Imagine? Don't need to. Been there. Done that. Its called "Cobol
Programming"


>
> Hmm.. I'd have to say that I agree and disagree.  It really depends on
what
> industry you're in.  If you're in the kind of industry where you're hiring
> newbie programmers all the time, then yes, it's important to be as
explicit as
> possible.  However, there are industries where programmers MUST be
experienced
> before they're hired.  Does it really make sense to make your code as
> newbie-ish as possible for them?  (Again, without being cryptic).
>
Here's the issue: (And there's no way of getting around the question.) How
is it that this MAKES MONEY FOR THE STOCKHOLDERS? (Sorry for shouting.)

All industries hire newbies. Even experienced programmers are newbies to
your code - otherwise they aren't new-hires. If I write simple, direct,
straightforward code with good comments, good structure, good documentation,
etc., then I've got code that a newbie to Language XXX can readily read and
grasp (hopefully). Does it *HURT* the experienced programmer that you didn't
write something in as few keystrokes as possible within Language XXX? I
don't think so. (Like I said, whenever someone else picks up your program
for the first time, they are a "newbie") Anything I do to help the newbie
understand what is going on is at worst, not going to hurt the experienced
programmer and at best will probably help him along as well.

Now there are some things which are inherently complicated. If I need
multitasking - that's going to be tough to express simply because it isn't a
simple thing to do. Can't help you there by picking some kind of notational
syntax perceived to be "better". I think it was Einstein who said "Things
should be made as simple as possible - but no simpler." I guess what I'd
prefer to avoid in a language syntax are the obvious pitfalls that
repeatedly create errors and inevitably cause confusion and
miscommunication. Doing that much accomplishes something. It will never make
E := M * C**2 ; be as simple to understand as Y := M * X + B ;


>
> Well, that's sort of going to the extreme.  If the syntax is a part of the
> language itself, then it should be readable by anyone well versed with the
> language.  "i++" is not cryptic since that's a part of the language.
>
Read before what I said about opening up the floodgates. Some features of a
language are *inherently* unsafe or encourage obfuscation or make it easy to
introduce errors. In C (and in a number of other languages) you have well
known "syntax traps" that make it easy to create compile time errors that
are hard to locate. Similarly, there are "semantic traps" that make it easy
to introduce run-time errors. (BTW, this is true of verbose languages like
Cobol as well). I'm in favor of structuring the notation of a language such
that it minimizes the risk of errors and maximizes the communication to the
reader. IMHO, C's terse notation works against these goals. C's semantics
work against these goals as well, but that's another debate.


> If it's a "clever" (ab)use of the language, then you may need to
reevaluate
> what you're doing.   I hate it when people try to cram 4 or 5 or more
different
> things into the same line.  I just love reading stuff like c = a+++++b.
(not)
>
I hear you. I agree with this. I'd prefer a language design that does not
ALLOW something like what you just described, no matter how much "expressive
power" can be gained for the attainment of Good And Noble goals. (Sort of an
"ends justifies the means" argument?) Just because someone might rarely (and
arguably) use this sort of notation to express something in a clear and
concise manner, does not mean I want to frequently (and not so arguably) see
these kinds of attrocities committed either because someone a) thought it
was "clever" or b) thought it was "Intuitively Obvious To Any *Competent*
Programmer" or c) both.

One of the reasons I like Ada so much is because the syntax and semantics
tends to avoid such obfuscations. Its not that you *can't* write bad code in
Ada. (nor is it hard to write "concise" code - as long as we aren't simply
counting keystrokes as the measure of "conciseness") Its just that it tends
to steer you towards more straightforward and direct expression of what you
intended to do. It also does an enormous amount of error checking and
disallows certain things that cause errors commonly. The syntax also avoids
common "syntax traps" found in other languages & makes it easier for the
compiler to pinpoint exactly where you mistyped something. If you can't
write good code in C, you aren't magically going to start writing good code
in Ada. However, I think Ada provides a lot more help to the programmer who
is capable of writing good code.


> I guess we're pretty much arguing the same thing at this point.  My own
> contention is that there are programmers who are needlessly verbose that
the
> code looks more complex than it really is.
>
Anything can be taken to extremes. I've seen Ada code where the
proliferation of types & subtypes got so bad that you couldn't tell the
players without a scorecard. I've seen Ada code where the programmers
thought tasks were so cool, they ended up using them like they were
procedrues - to no advantage and with subsequent synchronization problems.
Obviously, someone sent these dudes off to a class that taught Ada & OOD/OOP
and they came back with half an understanding and lots of enthusiasm. The
first attempt at using just about any language may result in drastically bad
code because the newbie doesn't have the experience needed to make judgement
calls about the things that are rather subjective. (How many subtypes should
a program have? How many tasks should a program be broken down into? There
are no iron-clad rules. Like pornography, I can't write you a uniform legal
description, but I know it when I see it.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Long names are doom ?

[Pete Thompson]

On Wed, 6 Jun 2001 11:25:28 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

<snipping of mostly agreements>


>I like the first better. But I dislike things like I++ - not so much that
>particular one, but all the subtle variations that can take place. It
>changes meaning if it is in front or behind - but that only makes a
>difference sometimes. It can be mixed with other interesting variations and
>things like +=, etc. In the end, the "terseness" possible with this kind of
>operator is just plain not worth it. Way too subject to abuse. Way too easy
>to misconstrue meaning in complicated cases. Often ambiguous in definition

Well, sure it's subject to abuse.  However, that's the fault of the programmer,
not the language itself.  I too froth at the mouth whenever someone makes a
stupid use of operator overloading in C++, or write unnecessary compound
statements.

>leading to "implementation dependent", reliant on side effects, Etc. So to
>save the few keystrokes needed for "I := I + 1 ;" I give you "I++" and open
>the floodgates for the "Betcha can't guess what *this* line does!!!" kind of
>coding. Better to be rid of it and insist on the few extra keystrokes needed
>for Fortran-ish expressions and avoid all the trouble that will inevitably
>come from that programmer who will insist that "It should be intuitively
>obvious to any *COMPETENT* C programmer..."

Maybe I've just been lucky enough to have never worked in a workplace with
programmers like that who insists on trying to look clever in their code, and
thus I have no problems like that.  Should I be forced to move on to a more
verbose language because other people had bad experiences? 

>> Hmm.. I'd have to say that I agree and disagree.  It really depends on
>what
>> industry you're in.  If you're in the kind of industry where you're hiring
>> newbie programmers all the time, then yes, it's important to be as
>explicit as
>> possible.  However, there are industries where programmers MUST be
>experienced
>> before they're hired.  Does it really make sense to make your code as
>> newbie-ish as possible for them?  (Again, without being cryptic).
>>
>Here's the issue: (And there's no way of getting around the question.) How
>is it that this MAKES MONEY FOR THE STOCKHOLDERS? (Sorry for shouting.)

You have deadlines.  Miss the deadlines and you're going to piss the
stockholders off.  More experienced people are generally faster than newbie
coders, and new hires with experience tend to hit the ground running faster.
No need to wait for them to learn the ins and out of the API that your company
happens to be using, if they already know it.  I'll explain more below.

>All industries hire newbies. Even experienced programmers are newbies to
>your code - otherwise they aren't new-hires. If I write simple, direct,
>straightforward code with good comments, good structure, good documentation,
>etc., then I've got code that a newbie to Language XXX can readily read and
>grasp (hopefully). Does it *HURT* the experienced programmer that you didn't
>write something in as few keystrokes as possible within Language XXX? I
>don't think so. (Like I said, whenever someone else picks up your program

If you're asking for my personal experiences, then yes it would hurt everyone
(including the shareholders and customers) if I needlessly broke the code up
into multiple statements that used up more clock cycles, especially if it's a
piece of code that needs to be called often.  I work in the gaming industry.
Speed is king.  Just make damn sure that you comment your algorithms.
Unfortunately, people do tend to try to be needlessly terse and cram many
instructions into a single line because they think that's a good way to
optimize when it in fact accomplishes nothing.

When hiring new people, we expect them to know at least the basics of the API
we're using  (DirectX, OpenGL, whatever), some 3D math, and some of the bells
and whistles.  We've got deadlines.  We can't afford to hire pure newbies.  A
certain level of experience is a must.  And yes, we do look for people with
good coding practices -- no sloppy stuff, please!  That'd just slow down the
other team members.  We once had a vacuum salesman with no programming
experience applying for a job... want him?  :)   Of course there are the odd
times when we do hire programmers from another industry, but we generally stick
them with the task of creating tools and utilities until they learn the gaming
fundamentals. Sometimes they're quite happy with creating tools, and never want
to work on games directly.

If I was working for, say, a bank, then yes I would write slow and reliable
code that would last for years and be easily readable by people 10 years down
the road.  If I was writing software for a weapons research facility, then I'd
be sweating over every line and be agonizingly descriptive (/* here is the
auto-destruct function.  I say again, here is the auto-destruct function.
WARNING! Danger Will Robinson Danger! */). 

However, working in the gaming industry is a bit unforgiving in the sense that
your code generally becomes obsolete fairly quickly.  Just about the only thing
we can keep from project to project are the libraries, interfaces, and
platform-independent functions, and even they may need changing as new
platforms ship.  Spend too long programming, and your game becomes obsolete
before it even ships, like a certain over-hyped game...
*cough*Daikatana*cough*.  As such, writing long-term code is a bit of a wasted
effort (unless if it's REALLY useful and generic such as a quicksort function),
and that time would be better invested in tweaking the eye-candy to attract
more customers.


>Read before what I said about opening up the floodgates. Some features of a
>language are *inherently* unsafe or encourage obfuscation or make it easy to
>introduce errors. In C (and in a number of other languages) you have well
>known "syntax traps" that make it easy to create compile time errors that
>are hard to locate. Similarly, there are "semantic traps" that make it easy
>to introduce run-time errors. (BTW, this is true of verbose languages like
>Cobol as well). I'm in favor of structuring the notation of a language such
>that it minimizes the risk of errors and maximizes the communication to the
>reader. IMHO, C's terse notation works against these goals. C's semantics
>work against these goals as well, but that's another debate.

Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and encourages
obfuscation.  However, it also promotes flexibility.  That's always been an
acknowledged trade-off in C/C++ - with flexibility comes responsibility.  I
don't see how you can clean up the notations to reduce bugs, though, short of
getting rid of pointers altogether (which I definitely DON'T want to see happen
in C/C++).  


>I hear you. I agree with this. I'd prefer a language design that does not
>ALLOW something like what you just described, no matter how much "expressive
>power" can be gained for the attainment of Good And Noble goals. (Sort of an

Well.. it's always hard to predict how creative the programmer can be.  Java
was supposed to be "clean"... of course it didn't take too long for people to
prove otherwise  :)    On the flip side, be too restrictive, and you could end
up with a dead language.  People complained about Pascal because it was so
"structured".

It really depends on the programmer - like you said, anything can be taken to
the extremes, and even the greatest language in the world can end up looking
horrible in the hands of a talented (ahem) programmer, and there's not much we
can do to "fix" this.  I've accepted this about C/C++:  I know it's not
perfect, and I do bitch about it off and on, but it works well for me for what
I need to do. 

A hammer's just so damn useful, but I still sometimes hit my thumb.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, on 06/06/2001
   at 03:53 PM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>More experienced people are generally faster than newbie coders,

FSVO faster. The newbies are less likely to take the time to do it
right. They may deliver the code faster, but with significant
downstream costs as bugs materialize.

"There's never time to do it right but there's always time to do it
over."

>If you're asking for my personal experiences, then yes it would hurt
>everyone (including the shareholders and customers) if I needlessly
>broke the code up into multiple statements that used up more clock
>cycles, especially if it's a piece of code that needs to be called
>often.

"You have to carve the bird at the joints. It is sound practice to
write code in pieces that naturally divide. It is wasteful and
unmaintainable to break the code up arbitrarily. In your environment,
the performance impact is part of the "joints" metric.

>People complained about Pascal because it was so "structured".

Some people. Other people complained about Pascal because it was too
unstructured and ineptly structured. Shileds up, Scotty.




-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Roedy Green]

On Thu, 07 Jun 2001 07:36:52 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote or quoted :

>FSVO faster. 
FSVO?




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.

Re: Long names are doom ?

[Jon Skeet]

Roedy Green <roedy@mindprod.com> wrote:
> On Thu, 07 Jun 2001 07:36:52 -0400, "Shmuel (Seymour J.) Metz"
> <spamtrap@library.lspace.org.invalid> wrote or quoted :
> 
> >FSVO faster. 
> FSVO?

"For suitable values of", I believe.

One of the more bizarre abbreviations I used to see on ucam.chat was 
TMBSNMOTW <foo> OWIWNPA, which stood for:

"This must be some new meaning of the word <foo> of which I was not 
previously aware."

(The source for this, of course, is The Hitch-hikers' Guide To The 
Galaxy, where there is an exchange that runs something like:

Arthur: Where are we?
Ford:   We're safe.
Arthur: Where, exactly?
Ford:   We're on a ship in the Vogon constructor fleet.
Arthur: Ah, I see. This must be some new meaning of the word "safe" of
        which I was not previously aware.

In fact, I believe the book has a slightly different way of putting it 
from the above, but the misquote has become reasonably widely known :)

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <acuvht0gtl5mkrc6s637vfeshb0b0tsl48@4ax.com>, on 06/07/2001
   at 10:01 PM, Roedy Green <roedy@mindprod.com> said:

>FSVO?

For some value of.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, Pete Thompson says...
>
>Well, sure it's subject to abuse.  However, that's the fault of the programmer,
>not the language itself.  I too froth at the mouth whenever someone makes a
>stupid use of operator overloading in C++, or write unnecessary compound
>statements.
..
>A hammer's just so damn useful, but I still sometimes hit my thumb.

Real-world tools are actually a damn good analogy here. For example, whenever
someone takes their fingers off with a table-saw, its the fault of the user.
However, that doesn't stop table-saw makers from putting guards and other safety
features on them, does it? Languages, like any other tool, can be designed with
user safety in mind, or they can be built in a way that practicly invites users
to maim themselves. Sure, its the user's own stupid fault when they do so. But
their first mistake was using the unsafely designed tool in the first place.

(I know, I know. Lawsuits are actually an issue here, and they aren't typically
in the software world. Please lets ignore that issue for a minute. No analogy is
perfect. )

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

My table saw has a guard over the blade that shields the user from
accidentally bumping into the blade, reduces the flying sawdust and helps
prevent the workpiece from kicking back if the blade hangs on something. It
is a very nice safety feature that protects me on a lot of occasions.
However, I *can* and *do* from time to time remove it when I've got to cut
some workpiece that makes the guard awkward or impossible to live with.

I think Ada is similar. It has lots of checking to help insure you don't
shoot yourself in the foot. However, when the need arises, you can
circumvent the safety features. C is more like a saw that never came
equipped with such safety features. You can't add them on after the fact
very easily and are unlikely to do so. Better to have them there and
occasionally take them off than never have them there and mostly operate
without a net.

Hey! Maybe we can get OSHA to mandate the use of Ada???

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Ted Dennison" <dennison@telepath.com> wrote in message
news:VLLT6.2273$bA3.110613@www.newsranger.com...
> Real-world tools are actually a damn good analogy here. For example,
whenever
> someone takes their fingers off with a table-saw, its the fault of the
user.
> However, that doesn't stop table-saw makers from putting guards and other
safety
> features on them, does it? Languages, like any other tool, can be designed
with
> user safety in mind, or they can be built in a way that practicly invites
users
> to maim themselves. Sure, its the user's own stupid fault when they do so.
But
> their first mistake was using the unsafely designed tool in the first
place.
>
> (I know, I know. Lawsuits are actually an issue here, and they aren't
typically
> in the software world. Please lets ignore that issue for a minute. No
analogy is
> perfect. )
>

Re: Long names are doom ?

[Pete Thompson]

On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:

Lawsuits over bugs?!  Say it ain't so!

In all seriousness, yes you could try to use safeguards, but there are cases
where you simply cannot defend someone from themselves.  How would you put
safeguards on a hammer?  A hammer's already pretty basic.  The only thing I
could think of is to tell someone to use an electric hammer instead, but that's
an entirely different tool to accomplish the same task.  Similarly, if
someone's so worried about pointers and memory, then I'd just tell him to use
Java instead.

But there are times where you just can't anticipate ahead of time what the
programmers may do... who woulda thunk that NASA would allow a simple
imperial/metric mistake to screw up a mission?  :) 





>In article <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, Pete Thompson says...
>>
>>Well, sure it's subject to abuse.  However, that's the fault of the programmer,
>>not the language itself.  I too froth at the mouth whenever someone makes a
>>stupid use of operator overloading in C++, or write unnecessary compound
>>statements.
>..
>>A hammer's just so damn useful, but I still sometimes hit my thumb.
>
>Real-world tools are actually a damn good analogy here. For example, whenever
>someone takes their fingers off with a table-saw, its the fault of the user.
>However, that doesn't stop table-saw makers from putting guards and other safety
>features on them, does it? Languages, like any other tool, can be designed with
>user safety in mind, or they can be built in a way that practicly invites users
>to maim themselves. Sure, its the user's own stupid fault when they do so. But
>their first mistake was using the unsafely designed tool in the first place.
>
>(I know, I know. Lawsuits are actually an issue here, and they aren't typically
>in the software world. Please lets ignore that issue for a minute. No analogy is
>perfect. )
>
>---
>T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Ted Dennison]

In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson says...
>
>On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:
>
>Lawsuits over bugs?!  Say it ain't so!

Yeah, if that were allowed, then Bell would have been killed over C long before 
the Justice Department had a change to break it up. :-)

>In all seriousness, yes you could try to use safeguards, but there are cases
>where you simply cannot defend someone from themselves.  How would you put
>safeguards on a hammer?  A hammer's already pretty basic.  The only thing I

Right, you can't. But where you can put in safety features to prevent common
accidents, like with a table-saw, most people would consider it practicly
irresponsible not to.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Larry Kilgallen]

In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:
> 
> Lawsuits over bugs?!  Say it ain't so!
> 
> In all seriousness, yes you could try to use safeguards, but there are cases
> where you simply cannot defend someone from themselves.  How would you put
> safeguards on a hammer?

Remember that in the good old US of A manufacturers of aluminum
ladders are obliged to attach labels telling the user not to lean
the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Marin David Condic]

Ladders are supposed to be so overly expensive here specifically because of
all the product liability insurance the manufacturers have to carry. What
I'd like to know is how come a woman can spill hot coffee in her lap, sue
McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
unsafe technology. (Comes The Revolution, the lawyers will be the second
ones up against the wall, right after the entire marketing department of
Cirrus Cybernetics Corporation! :-)

As for the hammer? I'd suggest OSHA require they all be wrapped in
styrofoam. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:FzmIx3$T4lbd@eisner.encompasserve.org...
> In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> writes:
> > On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com>
wrote:
> >
> > Lawsuits over bugs?!  Say it ain't so!
> >
> > In all seriousness, yes you could try to use safeguards, but there are
cases
> > where you simply cannot defend someone from themselves.  How would you
put
> > safeguards on a hammer?
>
> Remember that in the good old US of A manufacturers of aluminum
> ladders are obliged to attach labels telling the user not to lean
> the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Benjamin.Altman]

Cause you don't expect coffee do give you 3rd degree burns, but everyone knows
that the software is unsafe or buggy when they buy it (not excuse, but...)

Marin David Condic wrote:

> Ladders are supposed to be so overly expensive here specifically because of
> all the product liability insurance the manufacturers have to carry. What
> I'd like to know is how come a woman can spill hot coffee in her lap, sue
> McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
> sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
> unsafe technology. (Comes The Revolution, the lawyers will be the second
> ones up against the wall, right after the entire marketing department of
> Cirrus Cybernetics Corporation! :-)
>
> As for the hammer? I'd suggest OSHA require they all be wrapped in
> styrofoam. :-)
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> news:FzmIx3$T4lbd@eisner.encompasserve.org...
> > In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
> <blackpete@nowhere.somewhere.anywhere.com> writes:
> > > On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com>
> wrote:
> > >
> > > Lawsuits over bugs?!  Say it ain't so!
> > >
> > > In all seriousness, yes you could try to use safeguards, but there are
> cases
> > > where you simply cannot defend someone from themselves.  How would you
> put
> > > safeguards on a hammer?
> >
> > Remember that in the good old US of A manufacturers of aluminum
> > ladders are obliged to attach labels telling the user not to lean
> > the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Blaikie]

> Cause you don't expect coffee do give you 3rd degree burns, but everyone
knows
> that the software is unsafe or buggy when they buy it (not excuse, but...)

coffee is hot, quite often boiling when it passes through the filter, ne1
with 1/2 a brain could expect that.
and ppl are able to and have sued M$, but the result depends on who has the
money, obviously stacking the case in Micrososfts favour.
db

Re: Long names are doom ?

[Roedy Green]

On Fri, 8 Jun 2001 07:52:08 +1000, "Blaikie"
<david_blaikie@hotmail.com> wrote or quoted :

>coffee is hot, quite often boiling when it passes through the filter, ne1
>with 1/2 a brain could expect that.
>and ppl are able to and have sued M$, but the result depends on who has the
>money, obviously stacking the case in Micrososfts favour.

I will be very happy when someone wins the first software suit.  We
will finally see some major attention paid to writing bug-free
programs for the ordinary marketplace.

It will be like the move from building by eye to building with finite
element stress analysis.

We don't even attempt to treat software construction as a science.  




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.

Re: Long names are doom ?

[Marin David Condic]

When I was in kindergarden, the teacher gave us these sage words of advice:
"Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
the point. If it was cold, you would complain. Through your own
carelessness, a thing expected to be what it is is actually what it is and
it does you harm. That is the fault of McDonalds? OTOH, One *expects*
software to work just like one expects their car to work or their TV to
work. (O.K. We all know better, but why do we stand for it?) When it doesn't
do what it is expected to do, we let the manufacturer off the hook - even
when there are proven methods for making software more reliable and they are
not followed?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Benjamin.Altman" <benjamin.altman@noaa.gov> wrote in message
news:3B1FE1FE.B49AE27F@noaa.gov...
> Cause you don't expect coffee do give you 3rd degree burns, but everyone
knows
> that the software is unsafe or buggy when they buy it (not excuse, but...)
>
> Marin David Condic wrote:
>
> > Ladders are supposed to be so overly expensive here specifically because
of
> > all the product liability insurance the manufacturers have to carry.
What
> > I'd like to know is how come a woman can spill hot coffee in her lap,
sue
> > McDonalds for making the coffee hot & *win*, yet nobody seems to be able
to
> > sue Bell Labs or Micro$oft for manufacturing operating systems with
*known*
> > unsafe technology. (Comes The Revolution, the lawyers will be the second
> > ones up against the wall, right after the entire marketing department of
> > Cirrus Cybernetics Corporation! :-)
> >
> > As for the hammer? I'd suggest OSHA require they all be wrapped in
> > styrofoam. :-)
> >
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas    www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> > news:FzmIx3$T4lbd@eisner.encompasserve.org...
> > > In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
> > <blackpete@nowhere.somewhere.anywhere.com> writes:
> > > > On Thu, 07 Jun 2001 13:58:13 GMT, Ted
Dennison<dennison@telepath.com>
> > wrote:
> > > >
> > > > Lawsuits over bugs?!  Say it ain't so!
> > > >
> > > > In all seriousness, yes you could try to use safeguards, but there
are
> > cases
> > > > where you simply cannot defend someone from themselves.  How would
you
> > put
> > > > safeguards on a hammer?
> > >
> > > Remember that in the good old US of A manufacturers of aluminum
> > > ladders are obliged to attach labels telling the user not to lean
> > > the aluminum ladder against an overhead power wire.
>

Re: Long names are doom ?

[Eric The Read]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> When I was in kindergarden, the teacher gave us these sage words of advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm. That is the fault of McDonalds?

I don't know why I expect computer professionals to be more informed
about this sort of thing than the average person (more web-literacy,
maybe?  I don't know...) but you might wish to educate yourself a bit
more on the actual facts of the case.

* McDonald's had paid more than 700 claims of exactly that type at the
  point Ms. Leibeck sued them.  They knew the nature and severity of the
  injuries their coffee had caused.

* Ms Leibeck suffered full-thickness (or third-degree) burns over 6
  percent of her body, and was hospitalized for 8 days, undergoing
  (rather painful, I might editorialize here) skin grafts and debridement 
  treatments.

* McDonald's served their coffee 40 to 50 degrees Fahrenheit hotter than
  the industry norm.  The consultant who advocated this to them admitted
  he'd never done any safety analysis of that temperature.

* McDonald's QA manager admitted that company policy required coffee to
  be served at 185 degrees, +/- 5 degrees, and that burning hazards
  existed at temperatures above 140.  He further testified that
  McDonald's knew there was a risk of burns, but wasn't going to do
  anything about it.

* At the temperatures the coffee was served, a full thickness burn of
  human skin will only take about 2 to 7 seconds.  If it had been served
  even at 155 degrees, likely Ms. Liebeck would not have been seriously
  injured.  (A survey of Alberquerque McDonalds' afterward found coffee
  served at an average of 158 degrees.)

* The car Liebeck was in was stopped when she spilled the coffee, and she 
  was not in the driver's seat.

* Leibeck originally sued for only $20,000, roughly her hospital costs.
  The jury awarded her $160k, plus $2.7M for punitive damages, which
  latter award the judge later reduced to a mere $480k (three times
  compensatory damages).

Source: <URL:http://www.lectlaw.com/files/cur78.htm>

> OTOH, One *expects*
> software to work just like one expects their car to work or their TV to
> work. (O.K. We all know better, but why do we stand for it?) When it doesn't
> do what it is expected to do, we let the manufacturer off the hook - even
> when there are proven methods for making software more reliable and they are
> not followed?

That's the real problem, and the main obstacle, I think, is that nobody
has seriously tried to sue a software manufacturer for providing useless, 
buggy, crap.  At least, not that I'm aware of (corrections welcome).
Until we see consumers start caring about quality, feature creep will win 
the day, I fear.

Followups set to 'poster' for OT content; if you want to reply to the
last para, feel free.

-=Eric
-- 
The hardest thing in the world to understand is the income tax.
		-- Albert Einstein

Re: Long names are doom ?

[Dan Mercer]

In article <9fotpi$4k6$1@nh.pace.co.uk>,
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> When I was in kindergarden, the teacher gave us these sage words of advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm.

DELETIA

Much as I loathe taking this topic farther off-topic

The burden is on the producer to provide the product safely.
McDonalds sold the coffee at the drive through window.  It was
easily foreseeable that the coffee would sometimes spill.  Thus,
they needed to provide it in a safe container (a larger container
partially filled rather than a small container filled to the
brim), provide it with lids less likely to come off,  provide a
carrier, or at very minimum make sure the coffee would not burn. 
McD's failed in all these regards.  Coffee hot enough to cause
3rd degree burns is too hot to drink.  It's deliberately
overheated so it will still be hot when people get it home.
McD's biggest fault was overreaching and taking the lawsuit to
a conclusion.  They could and should have settled out of court for 1/10
the judgement (and no precedent).

-- 
Dan Mercer
damercer@mmm.com


> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
MORE DELETIA

Re: Long names are doom ?

[Roedy Green]

On Thu, 7 Jun 2001 18:04:32 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> You *expect* coffee to be hot - that's
>the point. If it was cold, you would complain.

Well put.  Further coffee is advertised to be "piping hot" and
software is advertised to be "a snap to use".

There whole classes of misleading advertising that we consider
acceptable. We don't demand they substantiate their claims. Lying is
so out of hand we just throw up our hands and blame the consumer if he
is stupid enough to take the claims at face value.

Here is my top ten list:

1. gross exaggeration, so the claim could not possibly be considered
true. I'm ok with this, e.g. if you buy x brand dish soap your family
will fight over who gets the privilege of doing the dishes.

2. psychics

3. religions and faith healers.

4. fast food that looks so different in reality from that displayed in
the commercial or posters in the restaurant.

5. Pills that cause you to lose weight.

6. That buying a product will noticeably enhance your sex appeal or
enhance your mood.  E.g. buying a Swiffer will cause you to start
incontrollably dancing with joy, even when confronted by a boot camp
sargent. see (1).

7. aphrodisiacs.

8. how 900 personnel really look and dress.

9. age defying creams and devices.  If there is such a thing, only
Barbra Streisand has enough money to afford it.

10. That software will actually help you get your work done.

Engineering and aviation were hit and miss affairs to start, but they
gradually got their act together, and for the most part, buildings,
bridges and planes don't fall down. We programmers are still in the
biplane era, unwilling to give up the romance of seat of the pants
flying.  Some day we will have rude awakening that our customers don't
quite see it that way.  It may come with the advent of software
rental.  See http://mindprod.com/projects.html#SOFTWARERENTAL It may
come with the first successful software malpractice suit.




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.

Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9fotpi$4k6$1@nh.pace.co.uk...
> When I was in kindergarden, the teacher gave us these sage words of
advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot -
that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm. That is the fault of McDonalds? OTOH, One *expects*
> software to work just like one expects their car to work or their TV to
> work. (O.K. We all know better, but why do we stand for it?) When it
doesn't
> do what it is expected to do, we let the manufacturer off the hook - even
> when there are proven methods for making software more reliable and they
are
> not followed?


Unfortunately, a software lawsuit would have little ground to stand on.
Imagine if McDonald's required all customers who order hot coffee to sign an
agreement before they are given the coffee where they acknowledge that the
coffee is hot and can cause burns and that the customer assumes all
responsibility for the proper handling of the coffee. If you got burnt from
the coffee would you be able to win a suit agains McDonald's? Not likely,
since you agreed to accept the responsibility.

Read most software license agreements and you'll find that most are like my
hypothetical coffee agreement. Here is a sample from an IBM license
agreement: "IBM does not warrant uninterrupted or error-free operation of
the Program or that we will correct all Program defects. You are responsible
for the results obtained from the use of the Program." And since "IBM WILL
LICENSE THE PROGRAM TO YOU ONLY IF YOU FIRST ACCEPT THE TERMS OF THIS
AGREEMENT. " then you don't really have a legal leg to stand on. They even
have clauses limiting their liability.
--
 Dale King

Re: Long names are doom ?

[James Kanze]

Dale King wrote:

> Unfortunately, a software lawsuit would have little ground to stand
> on.  Imagine if McDonald's required all customers who order hot
> coffee to sign an agreement before they are given the coffee where
> they acknowledge that the coffee is hot and can cause burns and that
> the customer assumes all responsibility for the proper handling of
> the coffee. If you got burnt from the coffee would you be able to
> win a suit agains McDonald's? Not likely, since you agreed to accept
> the responsibility.

Did you sign such an agreement when you bought your software?

> Read most software license agreements and you'll find that most are
> like my hypothetical coffee agreement. Here is a sample from an IBM
> license agreement: "IBM does not warrant uninterrupted or error-free
> operation of the Program or that we will correct all Program
> defects. You are responsible for the results obtained from the use
> of the Program." And since "IBM WILL LICENSE THE PROGRAM TO YOU ONLY
> IF YOU FIRST ACCEPT THE TERMS OF THIS AGREEMENT. " then you don't
> really have a legal leg to stand on. They even have clauses limiting
> their liability.

Can you read this agreement before purchasing?  If you aren't in
agreement, can you get a refund?

A license agreement is a contract.  It only exists if both parties are
in agreement.  IBM (or MS, or whoever) can say whatever they want, but
they cannot hold you to it unless you actively agree as well.  What
they are doing is about the same as if I added words at the bottom of
my posting, stating that the information within it is licensed, and by
reading the posting, you agree to pay me a consulting fee.

I don't know what the situation is in America, but I'm pretty sure
having read of a case here in Europe where such "licenses" were held
to be non-binding, because they lacked the informed agreement of one
of the parties.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Dan Mercer]

In article <3B25D5FB.15C9B240@dresdner-bank.com>,
James Kanze <James.Kanze@dresdner-bank.com> writes:
> Dale King wrote:
> 
>> Unfortunately, a software lawsuit would have little ground to stand
>> on.  Imagine if McDonald's required all customers who order hot
>> coffee to sign an agreement before they are given the coffee where
>> they acknowledge that the coffee is hot and can cause burns and that
>> the customer assumes all responsibility for the proper handling of
>> the coffee. If you got burnt from the coffee would you be able to
>> win a suit agains McDonald's? Not likely, since you agreed to accept
>> the responsibility.
> 
> Did you sign such an agreement when you bought your software?

The agreement is part of the installation process.  You can't
install the software unless you agree to the license terms.
This constitutes a legal "acceptance".

-- 
Dan Mercer
damercer@mmm.com

> 
>> Read most software license agreements and you'll find that most are
>> like my hypothetical coffee agreement. Here is a sample from an IBM
>> license agreement: "IBM does not warrant uninterrupted or error-free
>> operation of the Program or that we will correct all Program
>> defects. You are responsible for the results obtained from the use
>> of the Program." And since "IBM WILL LICENSE THE PROGRAM TO YOU ONLY
>> IF YOU FIRST ACCEPT THE TERMS OF THIS AGREEMENT. " then you don't
>> really have a legal leg to stand on. They even have clauses limiting
>> their liability.
> 
> Can you read this agreement before purchasing?  If you aren't in
> agreement, can you get a refund?
> 
> A license agreement is a contract.  It only exists if both parties are
> in agreement.  IBM (or MS, or whoever) can say whatever they want, but
> they cannot hold you to it unless you actively agree as well.  What
> they are doing is about the same as if I added words at the bottom of
> my posting, stating that the information within it is licensed, and by
> reading the posting, you agree to pay me a consulting fee.
> 
> I don't know what the situation is in America, but I'm pretty sure
> having read of a case here in Europe where such "licenses" were held
> to be non-binding, because they lacked the informed agreement of one
> of the parties.
> 

Re: Long names are doom ?

[Marin David Condic]

That's the part that gets legally questionable. In normal contract law,
there are many aspects that ride on your ability to inspect the goods for
sale. Do the goods match up with what is contracted? Are the goods
non-conforming? Have you accepted non-conforming goods sent by the seller in
leu of conforming goods? If I can't possibly inspect the software without
first installing it, how can the act of installing it constitute acceptance?
The whole thing is on legally shakey grounds.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Dan Mercer" <damercer@mmm.com> wrote in message
news:9g5as6$hbq$1@magnum.mmm.com...
>
> The agreement is part of the installation process.  You can't
> install the software unless you agree to the license terms.
> This constitutes a legal "acceptance".
>

Re: Long names are doom ?

[Dan Mercer]

In article <9g5ipg$roq$1@nh.pace.co.uk>,
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> That's the part that gets legally questionable. In normal contract law,
> there are many aspects that ride on your ability to inspect the goods for
> sale. Do the goods match up with what is contracted? Are the goods
> non-conforming? Have you accepted non-conforming goods sent by the seller in
> leu of conforming goods? If I can't possibly inspect the software without
> first installing it, how can the act of installing it constitute acceptance?
> The whole thing is on legally shakey grounds.

Considering the amount of legal talent applied to the problem,
I very much doubt they're on legally shakey grounds.   We could
debate the issue more,  but I would guess that the legal opinions
of amateurs are as amusing to lawyers as the depictions of
computers in the movies are to us.

-- 
Dan Mercer
damercer@mmm.com


> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> 
> "Dan Mercer" <damercer@mmm.com> wrote in message
> news:9g5as6$hbq$1@magnum.mmm.com...
>>
>> The agreement is part of the installation process.  You can't
>> install the software unless you agree to the license terms.
>> This constitutes a legal "acceptance".
>>
> 
> 
> 

Re: Long names are doom ?

[Roedy Green]

On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
quoted :

>Considering the amount of legal talent applied to the problem,
>I very much doubt they're on legally shakey grounds

The law in the US is just one part of the equation.  If even part of
the world community toughens the laws, you get the California effect.

E.g California creates stiffer emissions laws.  To play in that market
car makers must devise new technology to comply.  Eventually that
spins off to all jurisdictions.  It costs no more to do it right for
the other jurisdictions.

If Canada and Europe start demanding truth in advertising Americans
would immensely benefit.  It costs less to emit the good software to
everyone than maintain a separate buggy version.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Philip Anderson]

Roedy Green wrote:
> 
> If Canada and Europe start demanding truth in advertising Americans
> would immensely benefit.  It costs less to emit the good software to
> everyone than maintain a separate buggy version.

If Europe starts demanding anything which would cost US businesses
money, the US declares a trade war :-)


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Long names are doom ?

[Marin David Condic]

I don't think that would work. The "California Effect" in all likelyhood is
going to be to drive business out of California. (Notice how California has
steadfastly produced stringent environmental regulations that have basically
made it impossible to build power plants or affordable housing. Now property
values are astronomical and electricity is in short supply. Net effect:
Businesses and individuals start looking for other places to live & work.)
The Law Of Unintended Consequences is what's going to get you here...

If (hypothetically) California were to produce stringent product liability
regulations on software and/or advertising laws, etc. that attempted to make
software manufacturers responsible for defects in quality and workmanship,
you'd likely see some strange effects. For example - a "gray market" - I
don't sell my software in California because of the liability - I sell it on
the Internet from the Caymen Islands. If I *do* sell it in California, the
price tag goes *way* up to cover all the liability lawsuits. Lots of things
would happen, but I don't think one of them would be better software across
the board - at least not any time soon. (and in the long run, I'll be dead!)

Better to rely on market forces for this kind of thing. If someone came out
with an equivalent to Micro$oft Office & made it more reliable & stable,
they'd have some advertising edge. "We - unlike our unnamed competitors whos
initials are "Micro$oft" - stand behind our product with the following
guarantee....." IOW, if it is *possible* to build a better mousetrap then
the answer is to *build* it and start selling it. The world will follow.
(Notice the threat posed to Micro$oft by Linux? Better moustrap? Path beaten
to the door? Markets can work to solve these problems.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:enoditglutmp6d4bmlfaddt9qipf0n8cbp@4ax.com...
> On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
> quoted :
> The law in the US is just one part of the equation.  If even part of
> the world community toughens the laws, you get the California effect.
>
> E.g California creates stiffer emissions laws.  To play in that market
> car makers must devise new technology to comply.  Eventually that
> spins off to all jurisdictions.  It costs no more to do it right for
> the other jurisdictions.
>
> If Canada and Europe start demanding truth in advertising Americans
> would immensely benefit.  It costs less to emit the good software to
> everyone than maintain a separate buggy version.
>
>
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Ted Dennison]

In article <9g7r02$mni$1@nh.pace.co.uk>, Marin David Condic says...
>Better to rely on market forces for this kind of thing. If someone came out
>with an equivalent to Micro$oft Office & made it more reliable & stable,
>they'd have some advertising edge. "We - unlike our unnamed competitors whos

Its a fallacy that the market cares about quality. Sure users whine about lack
of it, once they get the product. But before that point, they just want the damn
product yesterday (and as cheap as possible), no matter how badly it works.
Mostly its us *developers* who care about quality. After all, who wants to spend
their life whole building shoddy crap? (Its rhetorical; please, don't answer.
:-) )

For a good reference on this subject read "Worse is Better" (
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html )

It also provides a pretty good explanation of why C is more widely used than
pretty much every language whose group this thread is crossposted to.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

That seems to be a misunderstanding of markets. Seems a few years ago, GM,
Ford & Chrysler were having all sorts of hardships over "Quality" because
apparently, once "Quality" was available from another source, people were
staying away from American automakers in droves.

"Quality" means different things to different people at different times.
Sometimes "Quality" is a nice crystal Stubenware wineglass. Sometimes
"Quality" is an inexpensive Dixie cup that will hold water for a brief time
before failing. "Quality" is not synonymous with "never breaks". A
quick-and-dirty program that patches some disk problem for me at zero cost
can "break" in unusual conditions that I never produce & still be "Quality"

If market forces won't favor reliable software, I submit that this needs to
be demonstrated. Find an unreliable product with no competing reliable
product available. Produce a reliable product at a similar price and with
similar features and with a similar marketing budget. (IOW, all other
parameters held constant) Will the public purchase the Reliable product or
the P.O.S.?

I think if we duplicated the functionality of - say - Netscape, only wrote
it in Ada so that it didn't periodically lock up, core dump, etc., & made it
available under similar terms, it would probably become the browser of
choice. (Of course, my current copy of Explorer seems to be working with
more reliability than the version of Netscape I have, so there *is* a better
quality product in the market. Hard to test the theory unless AdaBrowser
(tm) is more reliable than that.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:kbLV6.6795$pb1.259296@www.newsranger.com...
> In article <9g7r02$mni$1@nh.pace.co.uk>, Marin David Condic says...
>
> Its a fallacy that the market cares about quality. Sure users whine about
lack
> of it, once they get the product. But before that point, they just want
the damn
> product yesterday (and as cheap as possible), no matter how badly it
works.
> Mostly its us *developers* who care about quality. After all, who wants to
spend
> their life whole building shoddy crap? (Its rhetorical; please, don't
answer.
> :-) )
>
> For a good reference on this subject read "Worse is Better" (
> http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html )
>
> It also provides a pretty good explanation of why C is more widely used
than
> pretty much every language whose group this thread is crossposted to.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Wes Groleau]

> be demonstrated. Find an unreliable product with no competing reliable
> product available. Produce a reliable product at a similar price and with
> similar features and with a similar marketing budget. (IOW, all other
> parameters held constant) Will the public purchase the Reliable product or
> the P.O.S.?

One or two years ago, somebody either in comp.lang.ada or on Team-Ada
reported having tried that.  Said he/she lost a sale as follows:

"So why should I buy this instead of [brand X]?"

"Because mine doesn't crash"

"Who are you trying to fool?  Everybody knows all software crashes!"  CLICK.

(not an exact quote)


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Wes Groleau]

D
> > first installing it, how can the act of installing it constitute acceptance?
> > The whole thing is on legally shakey grounds.
> 
> Considering the amount of legal talent applied to the problem,
> I very much doubt they're on legally shakey grounds.   We could

I think the "grounds" are just firm enough for their lawyers
to stand on until the plaintiff (who works for a living)
runs out of legal fees.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9g5ipg$roq$1@nh.pace.co.uk>, on 06/12/2001
   at 01:16 PM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>That's the part that gets legally questionable. In normal contract
>law,

I assume that by "normal" you mean common law. Various states have
introduced legislation to make shrink-wrap licenses enforcable. 


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

Well, O.K., my usage may not be precise. I *do* mean "common law". There are
countries (and I think the State of Louisiana) that have "code" law. There
is something called the UCC which is increasingly accepted in most states
for dealing with business transactions. I have some passing familiarity with
all of this from a course in contract law I took for an MBA, but I'm no
expert by any stretch. The point was that there are circumstances under
which the UCC gets invoked or where you might be dealing with a state that
has "code" law for how to deal with the particulars of *this* situation.
Understanding what happens there means knowing what the code says. Then you
have the more general "common law" interpretations of when a contract
becomes a contract. When it comes to software licenses, I couldn't tell you
for sure that it falls under common law or if it comes under UCC. Therefore
my qualification of the statement.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b28b36a$1$fuzhry$mr2ice@va.news.verio.net...
> In <9g5ipg$roq$1@nh.pace.co.uk>, on 06/12/2001
>    at 01:16 PM, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> said:
>
> >That's the part that gets legally questionable. In normal contract
> >law,
>
> I assume that by "normal" you mean common law. Various states have
> introduced legislation to make shrink-wrap licenses enforcable.
>

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9gafcr$lsk$1@nh.pace.co.uk>, on 06/14/2001
   at 09:49 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>Well, O.K., my usage may not be precise. I *do* mean "common law".
>There are countries (and I think the State of Louisiana) that have
>"code" law. There is something called the UCC which is increasingly
>accepted in most states for dealing with business transactions. 

There's also a FPOS called UCITA that has passed in a couple of states
with some really anticonsumer provisions.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[James Kanze]

Dan Mercer wrote:

> In article <3B25D5FB.15C9B240@dresdner-bank.com>,
> James Kanze <James.Kanze@dresdner-bank.com> writes:
> > Dale King wrote:

> >> Unfortunately, a software lawsuit would have little ground to
> >> stand on.  Imagine if McDonald's required all customers who order
> >> hot coffee to sign an agreement before they are given the coffee
> >> where they acknowledge that the coffee is hot and can cause burns
> >> and that the customer assumes all responsibility for the proper
> >> handling of the coffee. If you got burnt from the coffee would
> >> you be able to win a suit agains McDonald's? Not likely, since
> >> you agreed to accept the responsibility.

> > Did you sign such an agreement when you bought your software?

> The agreement is part of the installation process.  You can't
> install the software unless you agree to the license terms.  This
> constitutes a legal "acceptance".

I've never signed anything when installing software.  I have clicked a
lot of buttons, but that's part of the operations necessary to install
the software.  I'd be very surprised if any court here would say that
just by clicking a particular button, particularly during a sequence
of button clicks, constituted accepting a contract.

Note that most software also comes with a README file.  I read them;
I'm a professional, and I'm often doing fairly complicated things.  My
wife, on the other hand, might start to read it, but would soon
realize that she doesn't understand any of the technical jargon
anyway.  And of course, she would not read anything further during the
installation process, supposing as well that it was technical jargon.
And would doubtlessly click on accept thinking it was just another
button for enter.  To make the machine do anything, you just click on
buttons until it does it, and the lables on the buttons don't really
mean anything.  After all, to stop the machine, she first clicks on a
button labled start.

In sum, a reasonable person cannot be expected to understand, or even
to read, the license before clicking on accept.  And thus, cannot be
held to have entered into a contract.

(This ignores the fact that much of the software on one of my machines
was actually installed by my son.  Who is underage, and cannot enter
into a legally binding contract anyway.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Blaikie]

> In sum, a reasonable person cannot be expected to understand, or even
> to read, the license before clicking on accept.  And thus, cannot be
> held to have entered into a contract.

a reasonable person is often not expected to understand most contracts they
sign.
db

Re: Long names are doom ?

[Wes Groleau]

> > In sum, a reasonable person cannot be expected to understand, or even
> > to read, the license before clicking on accept.  And thus, cannot be
> > held to have entered into a contract.
> 
> a reasonable person is often not expected to understand most contracts they
> sign.

It doesn't only happen in software. How many of us have bought a house or car,
been handed multiple double-sided legal sized pages of fine print, been told
to initial here, here, here, here, here, and here, and sign here" and obeyed.

How many of us even read the last paragraph before the signature?  The one
that says,
   "I have read and understood this document and have received a copy."

What, you read that paragraph?  So you were lying when you signed it?
Or you read 5,000 words per minute?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Ted Dennison]

In article <3B278996.4DE8D7A8@ftw.rsc.raytheon.com>, Wes Groleau says...
>
>It doesn't only happen in software. How many of us have bought a house or car,
>been handed multiple double-sided legal sized pages of fine print, been told
>to initial here, here, here, here, here, and here, and sign here" and obeyed.

I don't do that unless my lawyer has read it over already and is the one telling
me this. However, I can tell from the reactions I get when reading over those 20
page legal documents that this behavior is pretty unusual.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Roedy Green]

On Wed, 13 Jun 2001 10:41:10 -0500, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote or quoted :

>How many of us even read the last paragraph before the signature?  The one
>that says,
>   "I have read and understood this document and have received a copy."
>

Would there not be some principle that said if the vendor hid a clause
that you promised your first born son, that it would be unenforceable
because no reasonable person would expect to find such a clause in
such a contract.  Surely such a strange provision should be widely
known.

Part of the problem with trying to reform the legal rules of software
is that a reasonable person expects very little for his money.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> 
> On Wed, 13 Jun 2001 10:41:10 -0500, Wes Groleau
> <wwgrol@ftw.rsc.raytheon.com> wrote or quoted :
> 
> >How many of us even read the last paragraph before the signature?  The one
> >that says,
> >   "I have read and understood this document and have received a copy."
> >
> 
> Would there not be some principle that said if the vendor hid a clause
> that you promised your first born son, that it would be unenforceable
> because no reasonable person would expect to find such a clause in
> such a contract.  Surely such a strange provision should be widely
> known.

Various Names at Lloyds used an argument like this some years ago, that
they had been persuaded to sign unlimited-liability agreements by unscrupulous
syndicate managers who promised that they'd get rich. When asked to honour
the agreement they'd signed by forking out for insurance payouts all the
way to the bottom of their wallets, they squealed long and loud (and I
believe they managed to convince a judge to let them off the hook).

Personally I think that anyone who signs pieces of paper with scary words like
"unlimited liability" on them deserves everything they get, but then...

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9g5as6$hbq$1@magnum.mmm.com>, on 06/12/2001
   at 03:01 PM, damercer@mmm.com (Dan Mercer) said:

>The agreement is part of the installation process.  You can't install
>the software unless you agree to the license terms. This constitutes
>a legal "acceptance".

That egregious provision is in UCITA, but it's certainly not in common
law. I believe that in most states the terms must be presented at the
time of sale.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Larry Elmore]

Marin David Condic wrote:
> 
> Ladders are supposed to be so overly expensive here specifically because of
> all the product liability insurance the manufacturers have to carry. What
> I'd like to know is how come a woman can spill hot coffee in her lap, sue
> McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
> sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
> unsafe technology. (Comes The Revolution, the lawyers will be the second
> ones up against the wall, right after the entire marketing department of
> Cirrus Cybernetics Corporation! :-)

Try reading the instructions on a can of instant coffee. Most tell you
to heat water to boiling and pour it over the powder/crystals, stir it,
and then to enjoy it -- _carefully_ (dont gulp it) because the coffee
will be HOT. Duh...
 
> As for the hammer? I'd suggest OSHA require they all be wrapped in
> styrofoam. :-)

Though you'd never guess it from TV news, more small children die in the
US from drowning in large buckets than from firearms accidents. OSHA
carefully studied this. Among the recommended possible solutions
suggested by their committee were to require _holes_ in the bottoms of
large buckets, or rounded, non-flat bottoms so they can't stand up on
their own and so tip over! This got a lot of ridicule in the press some
years ago as a prime example of government bureaucrats at their finest.

Larry

Re: Long names are doom ?

[Gary Labowitz]

You (or OSHA) have got to be putting us on.
"Larry Elmore" <ljelmore@home.com> wrote in message
news:3B204C82.C2681D79@home.com...
>
> Though you'd never guess it from TV news, more small children die in the
> US from drowning in large buckets than from firearms accidents. OSHA
> carefully studied this. Among the recommended possible solutions
> suggested by their committee were to require _holes_ in the bottoms of
> large buckets, or rounded, non-flat bottoms so they can't stand up on
> their own and so tip over! This got a lot of ridicule in the press some
> years ago as a prime example of government bureaucrats at their finest.
>
> Larry

Re: Long names are doom ?

[Larry Elmore]

Gary Labowitz wrote:
> 
> You (or OSHA) have got to be putting us on.
> "Larry Elmore" <ljelmore@home.com> wrote in message
> news:3B204C82.C2681D79@home.com...
> >
> > Though you'd never guess it from TV news, more small children die in the
> > US from drowning in large buckets than from firearms accidents. OSHA
> > carefully studied this. Among the recommended possible solutions
> > suggested by their committee were to require _holes_ in the bottoms of
> > large buckets, or rounded, non-flat bottoms so they can't stand up on
> > their own and so tip over! This got a lot of ridicule in the press some
> > years ago as a prime example of government bureaucrats at their finest.

I wish I was putting you on. But remember, this is the same government
that also spent $15,000 (IIRC) on a study to determine whether tequila
makes Siamese fighting fish more aggressive than rum does...

Larry

Re: Long names are doom ?

[Roedy Green]

On Fri, 08 Jun 2001 03:54:03 GMT, Larry Elmore <ljelmore@home.com>
wrote or quoted :

>Among the recommended possible solutions
>suggested by their committee were to require _holes_ in the bottoms of
>large buckets,

I suppose eventually they will equip kids with cone shape collars like
they put on goats or dogs to keep them from licking themselves.

If we eliminated death by disease or old age, you would live on
average 200 years before you died by accident.  This suggests to me
that our ancestors will be insanely safety-minded from our point of
view.



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.

Re: Long names are doom ?

[Eric The Read]

Roedy Green <roedy@mindprod.com> writes:
> If we eliminated death by disease or old age, you would live on
> average 200 years before you died by accident.  This suggests to me
> that our ancestors will be insanely safety-minded from our point of
> view.

I imagine our ancestors will be long dead by then.  Our descendants,
OTOH....

-=Eric
-- 
Everything should be made as simple as possible, but not simpler.
    -- Albert Einstein
    -- BSD fortune file

Re: Long names are doom ?

[Roedy Green]

On 08 Jun 2001 11:06:10 -0600, Eric The Read <emschwar@rmi.net> wrote
or quoted :

>I imagine our ancestors will be long dead by then.  Our descendants,
>OTOH....

Thank you.  I stared at my post, knowing something was wrong, but that
word "descendant" just would not come to me.


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.

Re: Long names are doom ?

[Larry Elmore]

Roedy Green wrote:
> 
> On Fri, 08 Jun 2001 03:54:03 GMT, Larry Elmore <ljelmore@home.com>
> wrote or quoted :
> 
> >Among the recommended possible solutions
> >suggested by their committee were to require _holes_ in the bottoms of
> >large buckets,
> 
> I suppose eventually they will equip kids with cone shape collars like
> they put on goats or dogs to keep them from licking themselves.
> 
> If we eliminated death by disease or old age, you would live on
> average 200 years before you died by accident.  This suggests to me
> that our ancestors will be insanely safety-minded from our point of
> view.

Larry Niven wrote a good SF short story based on that very idea. I can't
remember the title, but the story was memorable (to me, anyway).

Larry

Re: Long names are doom ?

[tmoran]

>Real-world tools are actually a damn good analogy here. For example, whenever
>...
>(I know, I know. Lawsuits are actually an issue here, and they aren't typically
>in the software world.
  I await with interest the first lawsuit in which a harmed party sues
a software manufacturer for using known-dangerous techniques instead of
best practices.  ;)

Re: Long names are doom ?

[Wes Groleau]

> >I hear you. I agree with this. I'd prefer a language design that does not
> >ALLOW something like what you just described, no matter how much "expressive
> >power" can be gained for the attainment of Good And Noble goals. (Sort of an
> 
> Well.. it's always hard to predict how creative the programmer can be.  Java
> was supposed to be "clean"... of course it didn't take too long for people to
> prove otherwise  :)    On the flip side, be too restrictive, and you could end
> up with a dead language.  People complained about Pascal because it was so
> "structured".
> 
> It really depends on the programmer - like you said, anything can be taken to
> the extremes, and even the greatest language in the world can end up looking
> horrible in the hands of a talented (ahem) programmer, and there's not much we
> can do to "fix" this.  I've accepted this about C/C++:  I know it's not
> perfect, and I do bitch about it off and on, but it works well for me for what
> I need to do.
> 
> A hammer's just so damn useful, but I still sometimes hit my thumb.

Compare the last remark to the nested quote, then consider:

  Hit (What => Thumbnail, With => Hammer);
               ^^^^^ type mismatch

  -- #%^%*&$^%& stupid babysitter language won't let me do what I want!

  -- Let's see, ..... oh yeah:

  function Other_Nail is
        new Unchecked_Conversion (Source => Fingernail,
                                  Target => Construction_Nail);
  ...

  Hit (What => Other_Nail (Thumbnail),
       With => Hammer);

  -- #$%^#^% stupid verbose language has 95% more keystrokes than necessary!!!

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[James Kanze]

Pete Thompson wrote:

    [...]
> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
> encourages obfuscation.  However, it also promotes flexibility.

Just curious, but what can you do with pointer arithmetic in C/C++
that you couldn't do otherwise, in a cleaner fashion?

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Pete Thompson]

On Fri, 08 Jun 2001 16:31:12 +0200, James Kanze <James.Kanze@dresdner-bank.com>
wrote:

>Pete Thompson wrote:
>
>    [...]
>> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>> encourages obfuscation.  However, it also promotes flexibility.
>
>Just curious, but what can you do with pointer arithmetic in C/C++
>that you couldn't do otherwise, in a cleaner fashion?

Well... I'm not saying that there's anything that would be impossible to do
without pointer arithmetics -- there's always another way to do things, after
all.  I'm just saying that there are cases where using pointer arithmetics are
simply faster.  I find it convenient for when dealing with strings/substrings,
images, special effects, filters, masks, reading the system memory, etc.  One
might argue that arrays are an abstract form of pointer arithmetics.  Whether
you agree with that or not, that's up to you.  

The same argument could be applied to recursive functions (another thing that's
inherently unsafe and encourages obfuscation) - there's ALWAYS a way to do it
non-recursively and avoid the risk of clobbering the stack.  There are certain
things that it just makes sense for, though, such as partitioning.

I could use a nerf ball instead of a hammer to drive a nail into a wall.  Sure,
it'd take me a lot longer, but it'll still get the job done (given enough
decades), and at no personal danger!  :)  

Re: Long names are doom ?

[Larry Kilgallen]

In article <7q32itc596euq7tgic3qgd4qpov9bocaj5@4ax.com>, Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> On Fri, 08 Jun 2001 16:31:12 +0200, James Kanze <James.Kanze@dresdner-bank.com>
> wrote:
> 
>>Pete Thompson wrote:
>>
>>    [...]
>>> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>>> encourages obfuscation.  However, it also promotes flexibility.
>>
>>Just curious, but what can you do with pointer arithmetic in C/C++
>>that you couldn't do otherwise, in a cleaner fashion?
> 
> Well... I'm not saying that there's anything that would be impossible to do
> without pointer arithmetics -- there's always another way to do things, after
> all.  I'm just saying that there are cases where using pointer arithmetics are
> simply faster.  I find it convenient for when dealing with strings/substrings,
> images, special effects, filters, masks, reading the system memory, etc.  One
> might argue that arrays are an abstract form of pointer arithmetics.

Others would argue that arrays are a safe paradigm for doing what
is done with pointer arithmetic.

Re: Long names are doom ?

[James Kanze]

Larry Kilgallen wrote:
> In article <7q32itc596euq7tgic3qgd4qpov9bocaj5@4ax.com>, Pete
> Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> > On Fri, 08 Jun 2001 16:31:12 +0200, James Kanze
> > <James.Kanze@dresdner-bank.com> wrote:

> >>Pete Thompson wrote:

> >>    [...]
> >>> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe
> >>> and encourages obfuscation.  However, it also promotes
> >>> flexibility.

> >>Just curious, but what can you do with pointer arithmetic in C/C++
> >>that you couldn't do otherwise, in a cleaner fashion?

> > Well... I'm not saying that there's anything that would be
> > impossible to do without pointer arithmetics -- there's always
> > another way to do things, after all.  I'm just saying that there
> > are cases where using pointer arithmetics are simply faster.  I
> > find it convenient for when dealing with strings/substrings,
> > images, special effects, filters, masks, reading the system
> > memory, etc.  One might argue that arrays are an abstract form of
> > pointer arithmetics.

> Others would argue that arrays are a safe paradigm for doing what is
> done with pointer arithmetic.

Which was, of course, my point.  It only holds for real arrays,
though; not for the cheap imiations in C.  And there are a (very) few
exceptions; I find pointer arithmetic convenient when writing memory
management code (malloc or a garbage collector), for example.  But
most applications don't have to deal with that level, and for them,
broken arrays and pointer arithmetic are just a source of errors.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <FaDxOvYsY8oI@eisner.encompasserve.org>, on 06/08/2001
   at 08:15 PM, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)
said:

>Others would argue that arrays are a safe paradigm for doing what is
>done with pointer arithmetic.

That is, if they had never seen an array or had never seen a pointer.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Patricia Shanahan]

James Kanze wrote:
> 
> Pete Thompson wrote:
> 
>     [...]
> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
> > encourages obfuscation.  However, it also promotes flexibility.
> 
> Just curious, but what can you do with pointer arithmetic in C/C++
> that you couldn't do otherwise, in a cleaner fashion?
...

Manage memory. A memory allocator, such as malloc, or the corresponding
kernel code, or the code underlying "new", has a split view of memory.
It must perform calcuations to determine where to put the the newly
created object. It must return a pointer to it.

Patricia

Re: Long names are doom ?

[James Kanze]

Patricia Shanahan wrote:

> James Kanze wrote:

> > Pete Thompson wrote:

> >     [...]
> > > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe
> > > and encourages obfuscation.  However, it also promotes
> > > flexibility.

> > Just curious, but what can you do with pointer arithmetic in C/C++
> > that you couldn't do otherwise, in a cleaner fashion?
> ...

> Manage memory. A memory allocator, such as malloc, or the
> corresponding kernel code, or the code underlying "new", has a split
> view of memory.  It must perform calcuations to determine where to
> put the the newly created object. It must return a pointer to it.

True.  Although there is something to be said for considering the
memory as one big array, and the "pointers" as indexes into it.  In
fact, in this case, C's pointers have just enough type checking to get
in the way and make the code a sloppy mess of typecasting.  IMHO, a
better solution would be to use real arrays (and indexes) where arrays
are appropriate, and have an untyped pointer to raw memory for this
sort of thing.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 16:08:23 -0700, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> wrote or quoted :

>I feel the same way about code:  being verbose is all well and good, but
>pointless verbosity can do more harm than good. 

From the tone of the entire post, I suspect Pete is the kind of guy
team leaders dream of having as their right hand man.


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.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com>, on 06/05/2001
   at 04:08 PM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>I feel the same way about code:  being verbose is all well and good,
>but pointless verbosity can do more harm than good.

Pointless *anything* in code can do more harm then good, especially
pointless terseness.

>Does it really make sense to make your code as
>newbie-ish as possible for them? 

Why are you equating "readable" with "newbie"? I've been at this for
decades, and in my experience one of the signs of a newbie is that he
doesn't understand the importance of readable and maintainable code.
Please note that neither "terse" nor "verbose" will satisfy the
requirement; it has to be readable.

-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 22:20:32 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>>Does it really make sense to make your code as
>>newbie-ish as possible for them? 
>
>Why are you equating "readable" with "newbie"? I've been at this for
>decades, and in my experience one of the signs of a newbie is that he
>doesn't understand the importance of readable and maintainable code.
>Please note that neither "terse" nor "verbose" will satisfy the
>requirement; it has to be readable.

Because we've been talking about hiring newbie programmers in this thread.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <hqhvhtgalmjoa0arv9hj5tehsa3q6s44vl@4ax.com>, on 06/07/2001
   at 11:27 AM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>Because we've been talking about hiring newbie programmers in this
>thread.

We've also been talking about white space, but that doesn't make a
newbie white space. The fact that two concepts appear in the same
discussion doesn't make them synonymous, or even close.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Simon Wright]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> 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).

I would have agreed, I think, but an alternative strategy is the one
Martin Fowler mentions in Refactoring (essentially, use good
*operation* (aka subprogram) names, then you probably don't even need
the comments.

Of course, you end up with more subprograms.

Re: Long names are doom ?

[Pete Thompson]

On Mon, 04 Jun 2001 15:05:12 GMT, Ted Dennison<dennison@telepath.com> wrote:

>In article <aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com>, Pete Thompson says...
>>
>>...  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.

No, that is not what I mean.  Yes, it is quite bad to be so terse that the code
becomes obfuscated and unreadable  (side topic:  look up the obfuscated C
contest on goodle for a bit of fun).

I'm talking about terse in the sense that you get a better picture of the
overall picture in a few lines.  I'm talking about being terse for the sake of
readability, *NOT* for the sake of simply being terse.

Consider the following examples:

Terse way:

for (int i = 0; i < n; i++)
{
	cout << "i = " << i << endl;
}

Non-terse way:

for (int iIterationCounter = ITERATIONSTART; iIterationCounter <
iMaximumIteration; iIterationCounter = iIterationCounter + ITERATIONSTEP)
{
	cout << "iIterationCounter = " << endl;
}

You're going to have to look up the #define's to find out what those constants
mean in another file.

By design, this is a good thing, actually.  However, this can also lead to code
that's harder to read once you run into a good chunk of code that spans a
couple of pages that really could have been done in half a page and still be
just as readable (if not more so because it's all right in front of you).  

The first example is terse, but not necessarily cryptic as long as you don't
try to be terse for the sake of being terse.  A bad example of being terse
would be:

if (*i++ < ++j) *k++;

I don't want to be forced to think about operator precedence, ok?  :)

For those of you who are super-picky:  I am *NOT* advocating the use of
single-character variable names.  I (depending on the variable's scope) prefer

char* pClientName;

instead of:

char* p;
or char* pNameOfAClientInDatabase;

Bottom line:  don't be pointlessly terse and don't be pointlessly verbose
either.

I hope I've explained myself a bit better.

Re: Long names are doom ?

[Simon Wright]

Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:

> Terse way:
> 
> for (int i = 0; i < n; i++)
> {
> 	cout << "i = " << i << endl;
> }
> 
> Non-terse way:
> 
> for (int iIterationCounter = ITERATIONSTART; iIterationCounter <
> iMaximumIteration; iIterationCounter = iIterationCounter + ITERATIONSTEP)
> {
> 	cout << "iIterationCounter = " << endl;
> }

Given C, anyone whose standards required your second example would be
past praying for. There is an interesting value there (n) which is
probably less than obvious, and just "n" is probably terser than one
would like.

I've always found automations like

  for (int i = 0; i < sizeof(ARRAY)/sizeof(ARRAY[0]); i++) {
    // do something with ARRAY[i]
  }

helpful.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <glcqht423b2ik3sgrnitsoccvpl0rporoq@4ax.com>, on 06/05/2001
   at 12:56 PM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>You're going to have to look up the #define's to find out what those
>constants mean in another file.

The names should tell you what they mean. You don't need to know the
values.

>The first example is terse, but not necessarily cryptic as long as
>you don't try to be terse for the sake of being terse.  A bad
>example of being terse would be:

>if (*i++ < ++j) *k++;

I hate, loathe and despise C, yet I still find that code to be
perfectly understandable, with the exception of the variable names..


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Dale King]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b1ee2d5$2$fuzhry$mr2ice@va.news.verio.net...
> >The first example is terse, but not necessarily cryptic as long as
> >you don't try to be terse for the sake of being terse.  A bad
> >example of being terse would be:
>
> >if (*i++ < ++j) *k++;
>
> I hate, loathe and despise C, yet I still find that code to be
> perfectly understandable, with the exception of the variable names..


 Actually it is quite cryptic. The first question is why is k being
dereferenced and the value thrown away? Unless it is reading from some
memory mapped I/O device where the actual act of reading is important then
the dereference can be gotten rid of. If this were not true, this would
still be bad, because the compiler might optimize it away.

Wouldn't the following be more readable (keeping the bad variable names
since I don't know what the purpose of this code is)? It would certainlybe
much easier to step through this code and figure out what it is doing. And
yes I realize that this version does reorder some of the steps (such as i is
not incremented until after k is incremented, but if you have those sort of
constraints they should be spelled out and made explicit.

    j ++;

    if( *i < j )
    {
        k++;
    }

    i++;
--
 Dale King

Re: Long names are doom ?

[Donald L. Dobbs]

Dale King wrote:
> 
> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
> message news:3b1ee2d5$2$fuzhry$mr2ice@va.news.verio.net...
> > >The first example is terse, but not necessarily cryptic as long as
> > >you don't try to be terse for the sake of being terse.  A bad
> > >example of being terse would be:
> >
> > >if (*i++ < ++j) *k++;
> >
> > I hate, loathe and despise C, yet I still find that code to be
> > perfectly understandable, with the exception of the variable names..
> 
>  Actually it is quite cryptic. The first question is why is k being

===============

Here is some C code I had to contend with -- it adds a new dimension to
cryptic write-only code:

x=(--(p)->_cnt>=0?(*(p)->_ptr++=x)&0xff:_flsbuf(x&0xff,p))

Unless you were the original programmer of the above you don't have a
prayer on this one without some additional commentary somewhere...

===============

> dereferenced and the value thrown away? Unless it is reading from some
> memory mapped I/O device where the actual act of reading is important then
> the dereference can be gotten rid of. If this were not true, this would
> still be bad, because the compiler might optimize it away.
> 
> Wouldn't the following be more readable (keeping the bad variable names
> since I don't know what the purpose of this code is)? It would certainlybe
> much easier to step through this code and figure out what it is doing. And
> yes I realize that this version does reorder some of the steps (such as i is
> not incremented until after k is incremented, but if you have those sort of
> constraints they should be spelled out and made explicit.
> 
>     j ++;
> 
>     if( *i < j )
>     {
>         k++;
>     }
> 
>     i++;
> --
>  Dale King

Re: Long names are doom ?

[AG]

"Goran Larsson" <hoh@invalid.invalid> wrote in message
news:GELwCw.K0r@approve.se...
> In article <3B2056A5.86396F55@home.com>,
> Donald L. Dobbs <donaldldobbs@home.com> wrote:
>
> > Here is some C code I had to contend with -- it adds a new dimension to
> > cryptic write-only code:
>
> > x=(--(p)->_cnt>=0?(*(p)->_ptr++=x)&0xff:_flsbuf(x&0xff,p))
>
> > Unless you were the original programmer of the above you don't have a
> > prayer on this one without some additional commentary somewhere...
>
> I'm not the original programmer, but this is obviously the contents of a
> implementation specific macro for a broken version of the C stdio
> function putc.

Looks like you have just defined what the "obviously" means in the the
context
of the "of a implementation specific macro for a broken version of the C"
So, what about the hope for someone who really needs to read THAT?
And what's so "obvious" about that?

>
> Why are you taking extremely compiler specific code that is implemented
> as a macro expansion for speed as an example of how typical C code
> looks like?

I'm afraid I lost you there... Do you mean that this sort of thing is
something
compiler-specific thing and NOT acceptable by other C compilers? And if
it's NOT then how exactly is it C?

Re: Long names are doom ?

[AG]

"Goran Larsson" <hoh@invalid.invalid> wrote in message
news:GEnxK3.3n8@approve.se...

> Only two entities need to read that code:
>  * the author of this specific standard C library

Actually, the author doesn't really need to read it either - just type it in
;)

>  * the C compiler this standard C library is intended for

So, in other words it is a throw-away code? Written once and NEVER
under ANY circumstances to be revisited? Never needing ANY modifications and
totally free of any bugs present or introduced in the future by the changing
environment?

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B2056A5.86396F55@home.com>, on 06/08/2001
   at 04:38 AM, "Donald L. Dobbs" <donaldldobbs@home.com> said:

>Here is some C code I had to contend with -- it adds a new dimension
>to cryptic write-only code:

>x=(--(p)->_cnt>=0?(*(p)->_ptr++=x)&0xff:_flsbuf(x&0xff,p))

The problem that I have with that code is the variable names rather
than the syntax. Plug in appropriate variiable names and I might be
able to say whether some comments are necessary. Rewrite it with "if"
but using the same names and it wiol remain cryptic.


-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3b20009c$2@news.tce.com>, on 06/07/2001
   at 10:34 AM, "Dale King" <KingD@TCE.com> said:

> Actually it is quite cryptic. The first question is why is k being
>dereferenced and the value thrown away?

I must admit that I missed that one; i read the last value as (*k)++
instead of *(k++). But I haven't used C for a decade and a half;
someone using it on a daily basis would remember the precedence for
such common operators.

>Unless it is reading from some
>memory mapped I/O device where the actual act of reading is
>important then the dereference can be gotten rid of. If this were
>not true, this would still be bad, because the compiler might
>optimize it away.

I thought that the current C language had a means to suppress such
optimizations.

>Wouldn't the following be more readable <clipped>

>    j ++;
>    if( *i < j )
>    {
>        k++;
>    }
>    i++;

No. And it wouldn't do the same thing. I wouldn't throw away the
memory reference unless I knew that it wasn't needed.

-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[John English]

"Shmuel (Seymour J.) Metz" wrote:
> 
> In <3b20009c$2@news.tce.com>, on 06/07/2001
>    at 10:34 AM, "Dale King" <KingD@TCE.com> said:
> 
> > Actually it is quite cryptic. The first question is why is k being
> >dereferenced and the value thrown away?
> 
> I must admit that I missed that one; i read the last value as (*k)++
> instead of *(k++). But I haven't used C for a decade and a half;
> someone using it on a daily basis would remember the precedence for
> such common operators.

Not necessarily. I've come across C developers with many years experience
who occasionally write "if (a = b) ..." instead of "if (a == b)..."
because, even with all that experience, it stills looks plausible
and the fingers will still occasionally betray the mind. 

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 22:11:33 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <glcqht423b2ik3sgrnitsoccvpl0rporoq@4ax.com>, on 06/05/2001
>   at 12:56 PM, Pete Thompson
><blackpete@nowhere.somewhere.anywhere.com> said:
>
>>You're going to have to look up the #define's to find out what those
>>constants mean in another file.
>
>The names should tell you what they mean. You don't need to know the
>values.

Sometimes yes you do. You're building a GUI, and some components look a bit
off, or a colour looks funny.  Or you have absolutely no idea what the colour
"vermillion" looks like.  Or you want to add your own components.  

>
>>The first example is terse, but not necessarily cryptic as long as
>>you don't try to be terse for the sake of being terse.  A bad
>>example of being terse would be:
>
>>if (*i++ < ++j) *k++;
>
>I hate, loathe and despise C, yet I still find that code to be
>perfectly understandable, with the exception of the variable names..

I hope you aren't suggesting that this is the recommended way to write
statements.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <oghvhtkgpsd6stkffto8njpc0klcjduks2@4ax.com>, on 06/07/2001
   at 11:26 AM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>Sometimes yes you do. You're building a GUI, and some components look
>a bit off, or a colour looks funny.  Or you have absolutely no idea
>what the colour "vermillion" looks like.  Or you want to add your own
>components.  

No, if I'm reading the code I don't need to know that vermilion is
666, and knowing that won't tell me what it looks like. If it turns
out that 666 is the wrong value, I really to want to change it every
place it occurs, in the process changing a 666 that doesn't represent
vermilion but rather the weight of a foo.

>I hope you aren't suggesting that this is the recommended way to
>write statements.

I'd have to see them in context before I would issue a judgement.
Modulo variable names, I could well approve.

-- 
-----------------------------------------------------------
     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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[HarryO]

In article <3b1ee2d5$2$fuzhry$mr2ice@va.news.verio.net>, "Unknown"
<spamtrap@library.lspace.org.invalid> wrote:

>>if (*i++ < ++j) *k++;
> 
> I hate, loathe and despise C, yet I still find that code to be perfectly
> understandable, with the exception of the variable names..

Of course, it looks reasonable, but (and I realise it was probably
not a real piece of code) as it is, the code probably doesn't do what is
intended and certainly doesn't do what one might guess it does.

The reason is that the "++" binds more tightly than the "*", so all this
code actually does is increment k some number of times, hence the '*' is
totally superflous.  Persumably, what was intended was "(*k)++".

Just another example as to why "terse" can lead to  "buggy", I guess :-).

While I wouldn't (generally) make that mistake, because I know the
precedence, I'd probably be less terse and use "*k += 1" in this case or
maybe even "(*k) += 1" to make it obvious to the next person that this
code is fiddly.  Who knows, I might even go overboard and put in a
comment to explain it :-).

Re: Long names are doom ?

[John English]

Pete Thompson wrote:
> 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.

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:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <3B1CC17D.DD6F730C@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.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Jon Skeet]

Ted Dennison <dennison@telepath.com> wrote:
> In article <3B1CC17D.DD6F730C@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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Larry Kilgallen]

In article <sv5T6.507$SQ2.19684@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <3B1CC17D.DD6F730C@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.

I can rapidly enter (including underscores) what I think is Ada.

The fact that I have to revise it when the compiler gives me its
opinion regarding whether it is Ada does not seem to me to slow
the process much.

Re: Long names are doom ?

[James Kanze]

Ted Dennison wrote:

> In article <3B1CC17D.DD6F730C@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.

It depends on what the code is actually doing; I can knock out
boilerplate code pretty quickly thanks to touch-typing.  And even on
those two or three lines, typing them faster allows me to start
thinking about the next lines sooner.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[tmoran]

>It depends on what the code is actually doing; I can knock out
>boilerplate code pretty quickly thanks to touch-typing.  And even on
>those two or three lines, typing them faster allows me to start
>thinking about the next lines sooner.
  Has anyone ever published a time & motion study of programmers?
I've toyed with setting up a TV camera to look over my shoulder
and see just how much time actually is spent typing/waiting for
compiles/thinking/etc.  Hard data, not "it seems to me I'm always..."

Re: Long names are doom ?

[AG]

<tmoran@acm.org> wrote in message
news:c98U6.73619$%i7.55960791@news1.rdc1.sfba.home.com...
> >It depends on what the code is actually doing; I can knock out
> >boilerplate code pretty quickly thanks to touch-typing.  And even on
> >those two or three lines, typing them faster allows me to start
> >thinking about the next lines sooner.
>   Has anyone ever published a time & motion study of programmers?
> I've toyed with setting up a TV camera to look over my shoulder
> and see just how much time actually is spent typing/waiting for
> compiles/thinking/etc.  Hard data, not "it seems to me I'm always..."

I once read a study which measured the eye movement as compared
to the hand movement solving simple cognitive problems - like recognizing
a shape for what it is and making a choice amongst several possibilities.
Granted, it may not be directly related to the programming, but human
nature been what it is it's still suggestive. The eye movement outrun hand
movement (including involantory spastic movements) by more then two
orders of magnitude.
The way it was done was to attach tiny sensors to the eyeball, fingertips
etc.
Of course under those conditions *anyone* would be nervous but the results
were consistent as far as the ratios were concerned.

Re: Long names are doom ?

[Philip Anderson]

Pete Thompson wrote:
> 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

Re: Long names are doom ?

[James Kanze]

Pete Thompson wrote:

> 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.

That might be true for a C/C++ (or Java) programmer.  I doubt that it
is a problem for an Ada programmer, however -- the _ is about the only
key he needs to hit with his pinky.  (In practice, I've not found
using the pinky to be a problem.  The contorsions required by native
emacs, yes, but viper mode solves that.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Marin David Condic]

Things like underscores or hyphens or whatever are really substitutes for
the space key. I'd like someone to build a keyboard that had a
split-space-bar (or shift-space?) and have an editor map one side of the
space bar to the "non-space-space" for the language at hand. (usually
underscore, but IIRC, Jovial used the tick'mark as its virtual space...) I
think it would be more convenient than the usual shift-stretch one has to do
to get the underscore character...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James Kanze" <James.Kanze@dresdner-bank.com> wrote in message
news:3B1CECCA.65285DB3@dresdner-bank.com...
> Pete Thompson wrote:
>
> That might be true for a C/C++ (or Java) programmer.  I doubt that it
> is a problem for an Ada programmer, however -- the _ is about the only
> key he needs to hit with his pinky.  (In practice, I've not found
> using the pinky to be a problem.  The contorsions required by native
> emacs, yes, but viper mode solves that.)
>

Re: Long names are doom ?

[Philip Anderson]

Marin David Condic wrote:
> 
> Things like underscores or hyphens or whatever are really substitutes for
> the space key. I'd like someone to build a keyboard that had a
> split-space-bar (or shift-space?) and have an editor map one side of the
> space bar to the "non-space-space" for the language at hand. (usually
> underscore, but IIRC, Jovial used the tick'mark as its virtual space...) I
> think it would be more convenient than the usual shift-stretch one has to do
> to get the underscore character...

CORAL 66 conveniently allowed spaces in identifier names (but keywords
were quoted so they stood out).


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Long names are doom ?

[Marin David Condic]

Must have been kind of tough to parse.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3B1D0357.645C9FAE@amsjv.com...
>
> CORAL 66 conveniently allowed spaces in identifier names (but keywords
> were quoted so they stood out).
>

Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9fj23f$6oo$1@nh.pace.co.uk...
> Must have been kind of tough to parse.
>
> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
> news:3B1D0357.645C9FAE@amsjv.com...
> >
> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
> > were quoted so they stood out).

Not necessarily (I know nothing of CORAL in particular). I have brought the
subject up before (in the Java groups) asking whether having a language
allow spaces in identifiers would be a good thing. If you design the
language grammar well enough it would be easy to parse unambiguously. You
have to make sure that there is some form of operator or punctuation between
any identifiers. C-ish grammar wouldn't work because there is reliance on
whitespace to separate identifiers (e.g. int variable). Pascal-ish or
Modula-ish grammars would probably be pretty close except for the control
structures which use words to denote the beginning and end.

Re: Long names are doom ?

[Philip Anderson]

Marin David Condic wrote:
> 
> Must have been kind of tough to parse.

I doubt it since IIRC spaces were purely white space, just there for
readability with no syntactic significance; it's a few years since I
last wrote it, but I think "An Integer" and "AnInteger" would have been
regarded as the same.

Quoted keywords, semicolons and parentheses etc separated identifiers,
eg:
'Integer' I;


I imagine a compiler just ignored spaces, but anyway making things a
little harder for the compiler to make things easier for the
writer/reader should not bother anyone.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Long names are doom ?

[John English]

Marin David Condic wrote:
> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
> news:3B1D0357.645C9FAE@amsjv.com...
> >
> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
> > were quoted so they stood out).
> 
> Must have been kind of tough to parse.

Why? The lexer just treats whitespace as it would treat underlines
in Ada:
  identifier = letter (letter|digit|whitespace)*
or more likely ignores whitespace inside identifiers.

Using 'BEGIN' and 'END' was a pain, though, and even worse was that
comments were Algol-60 style:
  'COMMENT' ... ;
Leaving out the semicolon would silently lose the next statement and
was it nearly impossible to spot the lack of a near-invisible punctuation
mark... :-(

-----------------------------------------------------------------
 John English              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <3B1DF628.4951B79A@brighton.ac.uk>, John English says...
>
>Marin David Condic wrote:
>> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
>> news:3B1D0357.645C9FAE@amsjv.com...
>> >
>> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
>> > were quoted so they stood out).
>> 
>> Must have been kind of tough to parse.
>
>Why? The lexer just treats whitespace as it would treat underlines
>in Ada:

When I'm in one of those weirder moods and I think Intercal didn't go far
enough, I've occasionaly considered creating a language where the *only*
significant characters are the whitespace. Everything would have to coded using
sequences of spaces, tabs, and newlines, separated by text. Since the text
itself wouldn't matter, you could use all of it for comments. Thus this language
would be inherently self-documenting! :-)

I think I was inspired by my initial frustration with make's tabs.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

Space = '0'; Tab = '1'. Go forth and write machine code in binary.

Hard as it may be to imagine, I think such a language would be even *more*
perverse than my favorite perverse language: Befunge.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:vuqT6.996$bA3.39007@www.newsranger.com...
> In article <3B1DF628.4951B79A@brighton.ac.uk>, John English says...
> >
> >Marin David Condic wrote:
> >> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
> >> news:3B1D0357.645C9FAE@amsjv.com...
> >> >
> >> > CORAL 66 conveniently allowed spaces in identifier names (but
keywords
> >> > were quoted so they stood out).
> >>
> >> Must have been kind of tough to parse.
> >
> >Why? The lexer just treats whitespace as it would treat underlines
> >in Ada:
>
> When I'm in one of those weirder moods and I think Intercal didn't go far
> enough, I've occasionaly considered creating a language where the *only*
> significant characters are the whitespace. Everything would have to coded
using
> sequences of spaces, tabs, and newlines, separated by text. Since the text
> itself wouldn't matter, you could use all of it for comments. Thus this
language
> would be inherently self-documenting! :-)
>
> I think I was inspired by my initial frustration with make's tabs.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B1DF628.4951B79A@brighton.ac.uk>, John English <je@brighton.ac.uk> writes:
> Marin David Condic wrote:
>> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
>> news:3B1D0357.645C9FAE@amsjv.com...
>> >
>> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
>> > were quoted so they stood out).
>> 
>> Must have been kind of tough to parse.
> 
> Why? The lexer just treats whitespace as it would treat underlines
> in Ada:
>   identifier = letter (letter|digit|whitespace)*
> or more likely ignores whitespace inside identifiers.
> 
> Using 'BEGIN' and 'END' was a pain, though, and even worse was that
> comments were Algol-60 style:
>   'COMMENT' ... ;
> Leaving out the semicolon would silently lose the next statement and
> was it nearly impossible to spot the lack of a near-invisible punctuation
> mark... :-(

Languages certainly have come a long way from when it was possible to
lose subsequent lines due to lack of a comment terminator.  Now it is
just a matter of getting people to use the advanced languages.

Re: Long names are doom ?

[Matthew Woodcraft]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Things like underscores or hyphens or whatever are really substitutes for
> the space key. I'd like someone to build a keyboard that had a
> split-space-bar (or shift-space?) and have an editor map one side of the
> space bar to the "non-space-space" for the language at hand.

I've had shift-space producing underscore for some time, and it works
fine for me.

-M-

Re: Long names are doom ?

[Jacob Sparre Andersen]

Marin:

> Things like underscores or hyphens or whatever are really substitutes for
> the space key. I'd like someone to build a keyboard that had a
> split-space-bar (or shift-space?)

What a great idea. I have just fixed my setup.

I you use X, then the following command modifies the meaning of
Shift-Space to "_":

   echo "keycode  65 = space underscore" | xmodmap -

Put it a suitable place in your login scripts, and you should
be up and running.

Jacob
-- 
Warning: Dates in calendars are closer than they appear.

Re: Long names are doom ?

[Marin David Condic]

This must be some flavor of Unix? I've got a PC and a variety of tools used
to edit text that may not be configurable in that way. I'll have to see if I
can do something similar for AdaGIDE and CodeWright on a PC

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:3B1F56C8.28C881ED@nbi.dk...
> Marin:
>
> > Things like underscores or hyphens or whatever are really substitutes
for
> > the space key. I'd like someone to build a keyboard that had a
> > split-space-bar (or shift-space?)
>
> What a great idea. I have just fixed my setup.
>
> I you use X, then the following command modifies the meaning of
> Shift-Space to "_":
>
>    echo "keycode  65 = space underscore" | xmodmap -
>
> Put it a suitable place in your login scripts, and you should
> be up and running.
>
> Jacob
> --
> Warning: Dates in calendars are closer than they appear.

Re: Long names are doom ?

[Jacob Sparre Andersen]

Marin:

> This must be some flavor of Unix?

X, or "The X Window System", is the most commonly used graphical
user interface system for Unix-like operating systems[1].

> I've got a PC

So have I (in the "IBM compatible Intel 32 bit architechture
based computer" sense), but it may be because my machine is
running Linux while yours is running DOS, OS/2 or Windows.

> and a variety of tools used to edit text that may not be
> configurable in that way.

:-(

> I'll have to see if I can do something similar for AdaGIDE and
> CodeWright on a PC

I hope you can. It is actually quite nice, even though I haven't
gotten quite used to it yet.

Jacob
-- 
"simply because no one had discovered a cure for the universe as a
 whole - or rather the only one that did exist had been abolished"

Re: Long names are doom ?

[James Kanze]

Marin David Condic wrote:

> This must be some flavor of Unix?

He said is was X; X is the standard windows manager for Unix.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Simon Wright]

James Kanze <James.Kanze@dresdner-bank.com> writes:

> Marin David Condic wrote:
> 
> > This must be some flavor of Unix?
> 
> He said is was X; X is the standard windows manager for Unix.

Not really; it's the GUI support mechanism. The window manager is a
separate thing, there are lots of them out there.

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B1CECCA.65285DB3@dresdner-bank.com>, James Kanze <James.Kanze@dresdner-bank.com> writes:
> Pete Thompson wrote:
> 
>> 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.
> 
> That might be true for a C/C++ (or Java) programmer.  I doubt that it
> is a problem for an Ada programmer, however -- the _ is about the only
> key he needs to hit with his pinky.  (In practice, I've not found
> using the pinky to be a problem.  The contorsions required by native
> emacs, yes, but viper mode solves that.)

I find I use my ring finger, but I don't remember whether my typing
class in 1959 had underscore on the keyboard, or where it was located.

Re: Long names are doom ?

[James Kanze]

Roedy Green wrote:

> On Fri, 1 Jun 2001 11:09:30 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Jon Skeet]

James Kanze <James.Kanze@dresdner-bank.com> wrote:

> > 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.

Is that "no ambiguities if both people know a) the problem space and b) 
the naming convention", or no ambiguities regardless?

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[James Kanze]

Jon Skeet wrote:

> James Kanze <James.Kanze@dresdner-bank.com> wrote:

> > > 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.

> Is that "no ambiguities if both people know a) the problem space and
> b) the naming convention", or no ambiguities regardless?

The problem occurs when the naming convention gives semantic meaning
to aspects which aren't verbalized, like case.  If you have a variable
and a typename which only differ in the case of the initial letter,
there will be ambiguity when you talk about program text over the
telephone.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[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.....

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[AG]

"Marin David Condic" <marin.condic.auntie.spam@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?

Re: Long names are doom ?

[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;


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Simon Wright]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> > 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;

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

Re: Long names are doom ?

[Marin David Condic]

How about this: All type identifiers will be exactly 32 characters in
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vn17rv1x2.fsf@smaug.pushface.org...
> 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!
>

Re: Long names are doom ?

[Roedy Green]

On Fri, 01 Jun 2001 13:50:22 -0000, revbob@the.rectory (Rev. Bob 'Bob'
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.



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.

Re: Long names are doom ?

[Edward Rosten]

> On Fri, 01 Jun 2001 13:50:22 -0000, revbob@the.rectory (Rev. Bob 'Bob'
> 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

Re: Long names are doom ?

[James Kanze]

"Rev. Bob 'Bob' Crispen" wrote:

> The kindly Rev. overheard Alvaro Segura <asegura@facilnet.es> saying
> 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.

The plurial doesn't always work.  A type States would suggest that it
held several states, not just one.  A more general rule is to use
unqualified nouns as typenames, qualified nouns as variables.  So you
get:

    State currentState ;
    State previousState ;

Of course, what is qualified and what isn't depends on context.
HardwareState could be a type or a variable, according to whether you
consider the Hardware as a qualifier (which it is, grammatically), or
something fundamental to the type (as is often the case in programs).

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B177EF7.2A2470F4@facilnet.es>, Alvaro Segura <asegura@facilnet.es> writes:

> 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.

Re: Long names are doom ?

[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.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Jon Skeet]

Wes Groleau <wwgrol@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 
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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Wes Groleau]

Jon Skeet wrote:
> 
> Wes Groleau <wwgrol@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.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Jon Skeet]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:

> > 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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Georg Bauhaus]

Jon Skeet (skeet@pobox.com) wrote:
: Wes Groleau <wwgrol@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!

Re: Long names are doom ?

[Jon Skeet]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> Jon Skeet (skeet@pobox.com) wrote:
> : Wes Groleau <wwgrol@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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[John English]

Chris Smith 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.

"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              | mailto:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

pragma Tongue_In_Cheek (On) ;

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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B1411D0.3AAF42E7@ftw.rsc.raytheon.com...
>
> > 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
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Roedy Green]

On Wed, 30 May 2001 10:14:23 -0400, "Marin David Condic"
<marin.condic.auntie.spam@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.


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.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9f2v82$hp7$1@nh.pace.co.uk>, on 05/30/2001
   at 10:14 AM, "Marin David Condic"
<marin.condic.auntie.spam@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
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

Oh, I *have* a debugger with the Ada compiler I use. I just never turn it
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b1ad864$4$fuzhry$mr2ice@va.news.verio.net...
> 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?"
>
>

Re: Long names are doom ?

[Roedy Green]

On Mon, 4 Jun 2001 10:41:55 -0400, "Marin David Condic"
<marin.condic.auntie.spam@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.


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.

Re: Long names are doom ?

[Marin David Condic]

Java - while still not IMHO the best expression of the years of language
design research & development - was an improvement over C/C++ in many
respects. The designers *did* take out some of the worst aspects of C/C++
which greatly reduced the need to constantly watch the execution of code
through a debugger. This is a good thing.

You might be pleasantly surprised with Ada if you ever used it to develop a
serious program. Like any language, its hard initially to make the shift
from what you're used to to what the new language does, but once you become
fluent enough with it, you start finding it has some *really* nice
capabilities.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:os2oht834uarc6gmbjje2qgsu9dhqo7b8u@4ax.com...
> On Mon, 4 Jun 2001 10:41:55 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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.
>
>
> 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.

Re: Long names are doom ?

[James Kanze]

Marin David Condic wrote:

> Oh, I *have* a debugger with the Ada compiler I use. I just never
> turn it 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.

Why do you say this?  I've used C/C++ regularly for over 15 years, and
I don't use a debugger for anything other than for getting a stack
trace on a post-mortem.

Of course, my C/C++ code is riddled with assertions, so if there is an
error, the program generally falls over quite near the point of error,
rather than somewhere unrelated.  Java takes care of a (very) few of
the cases you have to handle be hand in C++: array bounds, for
example.  But on the whole, I've found debugging a lot more difficult
in Java.  No assertion, no enforcement of contracts at the interface
level, etc.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Steve Bellenot]

In article <3B0DBD4A.82943473@my-deja.net>,
00001111  <00001111@my-deja.net> wrote:
>
> Hi All,
>
>  Anybody use variables/names longer than 31 character
>and finds it really useful ?
>
>Then please respond  why, where, when.
>I have folks here in comp.lang.fortran who 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.

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)

Re: Long names are doom ?

[Peter Fitzgibbons]

bellenot@math.fsu.edu (Steve Bellenot) wrote in message news:<9ekrc2$hk0$1@news.fsu.edu>...
> In article <3B0DBD4A.82943473@my-deja.net>,
> 00001111  <00001111@my-deja.net> wrote:
> >
> the number n ... is more
> likely that the answer is 42, but it could be 31.

As in the answer to life.

6 x 9
     (13)

Re: Long names are doom ?

[Marin David Condic]

If you're going to have an arbitrary and capricious limit on identifier
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Steve Bellenot" <bellenot@math.fsu.edu> wrote in message
news:9ekrc2$hk0$1@news.fsu.edu...
> 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.

Re: Long names are doom ?

[Roedy Green]

On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
<marin.condic.auntie.spam@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.


-
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.

Re: Long names are doom ?

[Larry Hazel]

Roedy Green wrote:
> 
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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.
> 
> -
> 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.

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

Re: Long names are doom ?

[Larry Kilgallen]

In article <cubtgtcnrrnkb1nj3khtapapse7cbsl20q@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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.

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> 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:je@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
-----------------------------------------------------------------

Re: Long names are doom ?

[Roedy Green]

On Tue, 29 May 2001 10:41:09 +0100, John English <je@brighton.ac.uk>
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.

Re: Long names are doom ?

[Marin David Condic]

Welcome to the Tower of Babel. It shall always be thus. Better to find ways
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:utt7hto6rm0o9a8qked9muns28n7lrnvi6@4ax.com...
> 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.
>

Re: Long names are doom ?

[Marin David Condic]

I probably should have put a :-) next to that comment. See "A Hitchhikers
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:cubtgtcnrrnkb1nj3khtapapse7cbsl20q@4ax.com...
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@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.
>
>
> -
> 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.
>

Re: Long names are doom ?

[Kent Dahl]

Marin David Condic wrote:
> or be set to some really big number that in practice will never be
> exceeded - like 256 or 512.)

I keep seeing 256 and thinking of Visual C++ 6.0 warnings that the STL
identifiers get truncated. So the arbitrary large (from a human point of
view)  256 limit is pretty small (from a machine point of view).

Oh, but then again C++ is off-topic on all the ng's :-P

-- 
<[ Kent Dahl ]>================<[ http://www.stud.ntnu.no/~kentda/ ]>
  )____(stud.techn.;ind.�k.data)||(softwareDeveloper.at(Trustix))_( 
 /"Opinions expressed are mine and not those of my Employer,      "\
( "the University, my girlfriend, stray cats, banana fruitflies,  " )
 \"nor the frontal lobe of my left cerebral hemisphere.           "/

Re: Long names are doom ?

[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

Re: Long names are doom ?

[tmoran]

>   Anybody use variables/names longer than 31 character
> 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.

Re: Long names are doom ?

[Patrick Logan]

"00001111" <00001111@my-deja.net> wrote
in message news:3B0DBD4A.82943473@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:patrickdlogan@home.com

Re: Long names are doom ?

[Florian Weimer]

00001111 <00001111@my-deja.net> writes:

>   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.

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B0DBD4A.82943473@my-deja.net>, 00001111 <00001111@my-deja.net> writes:

>   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.

Re: Long names are doom ?

[Marin David Condic]

Is this a troll? :-)

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.condic@pacemicro.com
Web:      http://www.mcondic.com/

"00001111" <00001111@my-deja.net> wrote in message
news:3B0DBD4A.82943473@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
>
>

Re: Long names are doom ?

[tmoran]

> Anybody use variables/names longer than 31 character
> ...
> I have folks here in comp.lang.fortran who will die claiming that
> [various objections to long names]

  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.

Re: Long names are doom ?

[Marin David Condic]

Data is A Good Thing. What these sort of style debates degenerate to is
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.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:EJwP6.33931$%i7.27394225@news1.rdc1.sfba.home.com...
>   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.

Re: Long names are doom ?

[Jon Skeet]

tmoran@acm.org <tmoran@acm.org> wrote:
> > Anybody use variables/names longer than 31 character
> > ...
> > I have folks here in comp.lang.fortran who will die claiming that
> > [various objections to long names]
> 
>   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.

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.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Tom Spilman]

    People will abuse language features no matter what precautions are taken
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" <00001111@my-deja.net> wrote in message
news:3B0DBD4A.82943473@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
>
>

Re: Long names are doom ?

[Gary Scott]

Hi, I think that none of these points being made were lost on the
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).

Tom Spilman wrote:
> 
>     People will abuse language features no matter what precautions are taken
> 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" <00001111@my-deja.net> wrote in message
> news:3B0DBD4A.82943473@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
> >
> >


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Long names are doom ?

[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.

Re: Long names are doom ?

[Phil K]

00001111 <00001111@my-deja.net> wrote in message news:<3B0DBD4A.82943473@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


Anyone who has worked on a code generator has probably found that
generated names are often longer than expected.  They often contain
class, method, and context information, which often leads to more than
31 characters.  They have probably also found that making readable
code from a generator is not always the easiest thing to do.  At the
same time though, those long names often make it absolutely clear
where the names came from.  You know exactly which file and often
where in the file it came from.

-PK