IDENTIFIERS in Upper Case

IDENTIFIERS in Upper Case

[Charles H. Sampson]

     Please don't let this be the start of another flame war.  I really 
need a piece of factual information, rather than opinions.  I've got 
plenty of opinions myself.

     I've heard it said that of all the possible case conventions that 
could be used in programming, the worst possible one is to require iden-
tifiers to be all upper case.  (This is one of those opinions that I 
agree with.)  Often when I've heard this, there has been either an ac-
company statement or an implication that studies have been done showing 
that this convention reduces comprehension, compared to the all-lower-
case or the initial-caps ones.  Can anyone point me toward any such 
study?  I doesn't even have to be on the Internet.  A reasonably acces-
sible journal would be fine.

     I poked around in the FAQ and didn't find anything, which is sur-
prising given the bandwidth that has been spent on the subject of case.
 
				Charlie

Re: IDENTIFIERS in Upper Case

[Matthew Heaney]

In article <1997Mar26.185431.12742@nosc.mil>, sampson@cod.nosc.mil (Charles
H. Sampson) wrote:

>     I've heard it said that of all the possible case conventions that 
>could be used in programming, the worst possible one is to require iden-
>tifiers to be all upper case.  (This is one of those opinions that I 
>agree with.)  Often when I've heard this, there has been either an ac-
>company statement or an implication that studies have been done showing 
>that this convention reduces comprehension, compared to the all-lower-
>case or the initial-caps ones.  Can anyone point me toward any such 
>study?  I doesn't even have to be on the Internet.  A reasonably acces-
>sible journal would be fine.

The book you want - and the book every software engineer should read - is
Designing The User Interface, by Ben Scheiderman.  In the chapter 9 (of the
1st ed), Printed Manuals, Online Help, and Tutorials, he sites a study (by
Moskel) that showed comprehension scores were higher for lower-and-upper
case text.

There's also a quote (I know it's in the 2nd ed, but that's at work) that
the reading speed for mixed case is a certain percent faster (15%?) than
reading all-uppercase text.

You can contact Dr. Scheiderman at the addresses below.  He'll have the
definative answer!

<mailto:ben@cs.umd.edu>
<http://www.cs.umd.edu/users/ben/index.html>

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: IDENTIFIERS in Upper Case

[Bob Collins]

In article <1997Mar26.185431.12742@nosc.mil>, sampson@cod.nosc.mil
(Charles H. Sampson) wrote:

>      I've heard it said that of all the possible case conventions that 
> could be used in programming, the worst possible one is to require iden-
> tifiers to be all upper case.  (This is one of those opinions that I 
> agree with.)  Often when I've heard this, there has been either an ac-
> company statement or an implication that studies have been done showing 
> that this convention reduces comprehension, compared to the all-lower-
> case or the initial-caps ones.  Can anyone point me toward any such 
> study?  I doesn't even have to be on the Internet.  A reasonably acces-
> sible journal would be fine.

Many reading studies have been done for general text (not programs)
that all seem to indicate that all uppercase "requires concentrated
attention and is slow to decipher." (Jan White, _Graphic design for
the electronic age_) One reason is the monotonous rectangularity of
uppercase text. Lowercase letters differ from each other in shape
and so are easier to recognize -- ascenders, descenders, and their
lack provide distinctive visual patterns. Even the dot over the "i"
helps to distinguish "i" from "m," "n," and "v" in handwritten text.

However the Ada "hiccup" style that the otherwise impeccably brilliant
Robert Dewar favors (hiccup is due to White and means the up-and-down
nature of The_Quick_Brown_Fox) seems to impede reading as well,
which is probably why cigarette warnings favor the hiccup style
("The Surgeon General Has Determined That ..."). Program text is
probably most easily read using a proportional font, with true
ascenders and descenders, and using mostly lowercase for identifiers,
as in the_quick_brown_fox. Tabs can be used for lining up columns.
Indeed, it might help to capitalize the first word in each statement
as a visual clue:

      If a > b then
         Some_other_procedure (a, d);
      else
         B := some_other_function (a, d);
      end if;

(P.S. I know That RD just favors a consistent style and is flexible
      enough to adopt any style. Consistency is good.)

                         Bob Collins, collins@cs.wm.edu

Re: IDENTIFIERS in Upper Case

[Steve Doiel]

In article <collins-2703970617290001@ratbert.cs.wm.edu>, collins@cs.wm.edu 
says...

>Many reading studies have been done for general text (not programs)
>that all seem to indicate that all uppercase "requires concentrated
>attention and is slow to decipher." (Jan White, _Graphic design for
>the electronic age_) One reason is the monotonous rectangularity of
>uppercase text. Lowercase letters differ from each other in shape
>and so are easier to recognize -- ascenders, descenders, and their
>lack provide distinctive visual patterns. Even the dot over the "i"
>helps to distinguish "i" from "m," "n," and "v" in handwritten text.
>
The keynote address at Tri-Ada 95 shed a lot of light on this subject
for me.  A small part of the subject was pattern recognition.

Take for example the following code

  IF a < b THEN
    DoProc1( arg )
  ELBE
    DoProc2( arg )
  END IF;

You may (or may not) have noticed that I misspelled the word 'ELSE'.  I
occasionally have the compiler catch such a misspelling for me.

Ok.  What's my point?  My point is that when you look at the
construct you don't necessarily read the keywords.  When you see the
structure, particularly if it is consistantly formatted, you recognize
the construct and look directly to the condition for the IF and the
actions taken for each branch.

It's much the same as when you see a stop sign.  You may not actually read
the word "STOP", but rather you recognize the shape of the sign and know
what it is immediately.

It is for this reason that I believe that whatever convention you choose
it should be one that allows as much instant pattern recognition as possible.

The coding convention we use is more elaborate than others I have heard
suggested but conveys more information at a glance.

>
>(P.S. I know That RD just favors a consistent style and is flexible
>      enough to adopt any style. Consistency is good.)
>
>                         Bob Collins, collins@cs.wm.edu
Agreed.

Steve Doiel
steved@pacifier.com

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

iBy the way Steve, here is what GNAT gives for your little example:

     1. PROCEDURE Doiel IS
     2. BEGIN
     3.   IF a < b THEN
     4.     DoProc1( arg )
                          |
        >>> missing ";"

     5.   ELBE
          |
        >>> incorrect spelling of keyword "ELSE"

     6.     DoProc2( arg )
                          |
        >>> missing ";"

     7.   END IF;
     8. END;


(Hmm! I guess your great capitalization style did not let you notice
the missing semicolons :-) I wonder if that is because the upper case
keywords distracted you? :-)

Note that GNAT does not discriminate, its error circuits work better 9if
you use a consistent style -- any of the style commonly used, including
Steve's are fine, but it learns your style from the program, and uses
this style for both error messages and error recovery (notice the
upper case ELSE in the error message).

Re: IDENTIFIERS in Upper Case

[Doug Smith]

In article <dewar.859561259@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

[snip]
> Note that GNAT does not discriminate, its error circuits work better 9if
> you use a consistent style -- any of the style commonly used, including
> Steve's are fine, but it learns your style from the program, and uses
> this style for both error messages and error recovery (notice the
> upper case ELSE in the error message).

Very nice! I had not noticed what GNAT was doing; since my style was
consistent, GNAT seemed to be using the same style..and I thought is
was because we agreed on what the best style was (how arrogant of me).

Now, with most LSE's handling additional formatting such as bold, italics,
font size, color, etc., what would be a good layout?

I've read the three Tufte books, and suspect there is a superior presentation
style that would convey the most information, efficiently. Earlier messages
mentioned color, and Tufte recommends earth tones (don't worry, that includes
an amazing variety). [see www.amazon.com and search on author]

He also tells us to use the "smallest effective
difference"; For example, if you wish to distinguish between variables
defined locally in a procedure, and variables defined in the package
body within which the procedure is defined, use just enough difference
(say, in shade of blue) to always tell which kind of variable it is.
That way, differences between variabls and procedures
can use a more significant difference, such as blue vs brown.

Also, as we begin integrating graphic presentations with the code:
<http://sw-eng.falls-church.va.us/cgi-bin/webada/file?template=surfada.html&file=/export/user_data/ada_source/dsmith.clark.net/sort.ads>
there are other design principles we will want to address.

I doubt the capitalization style will make the readability
issue for anyone's code, although it may break it.

Doug
<mailto:dsmith@clark.net>

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

Steve says

<<The coding convention we use is more elaborate than others I have heard
suggested but conveys more information at a glance.>>

Not to me it doesn't, it is completely unreadable. And that is because I
am used to a different style. But the trouble is that almost all Ada
programmers are also used to a different style.

I find odd-ball outliers like this in the style debate to be an active
nuisance to the goal of comfortable interchange of code. It's actually
surprising that the C community, undisciplined in so many respects,
and unwilling in so many respects to be consistent (consider the
bitter {} debate), is in fact willing to be highly conforming when
it comes to capitalization issues.

Whereas the Ada community, normally so disciplined in such matters (e.g.
nearly everyone more or less follows RM style for layout) has a small
but noisy minority pushing various peculiar capitalization styles.

Note that I am using peculiar here in its original meaning of different
or unique styles, not as meaning strange or wrong. Steve alledges that
the style they follow is more readable, but of course he has no data
for this allegation, so it remains just an anecdotal claim. What is
surely the case is that it clashes with accepted norms, making it
harder to integrate outside people and outside code. 

In the worst case, what happens is that you get people who absolutely
refuse to conform. I remember that one person at Alsys absolutely
insistned on using mixed case. As a result, no one else in the company
would touch his code. Automatic pretty printing does not resolve this
situation, because of the issue of configuration control (what version
is checked in, neither answer is adequate to both parties in practice,
especially since it is hard to generate mixed case automatically).

I think the reason that the situation is a mess in Ada is that the
original reference manual recommended the all upper case identifier
style, and right from the word start, the community fragmented into
the purists who insisted on following this recommendation (perhaps
including some who objectively felt it was better), and a large
group of people who could not stand all upper case.

Re: IDENTIFIERS in Upper Case

[Robert A Duff]

In article <dewar.859560724@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I think the reason that the situation is a mess in Ada is that the
                                            ^^^^
>original reference manual recommended the all upper case identifier
>style, and right from the word start, the community fragmented into
>the purists who insisted on following this recommendation (perhaps
>including some who objectively felt it was better), and a large
>group of people who could not stand all upper case.

That sounds like a correct assessment to me.  But I wouldn't call it
such a "mess".  We seem to be pretty much converging on the Mixed_Case
convention.  Almost all new code I see is written in that style, and
probably more than half of all old code I've seen.  It's not universal,
but getting there.

- Bob

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

Bob says

<<That sounds like a correct assessment to me.  But I wouldn't call it
such a "mess".  We seem to be pretty much converging on the Mixed_Case
convention.  Almost all new code I see is written in that style, and
probably more than half of all old code I've seen.  It's not universal,
but getting there.>>

I agree we are getting there, but there are irritating holdouts (that's
why I dislike Mike Feldman's choice, it teaches a whole generation of
Ada programmers to get used to a "non-standard" style). Still, I agree
that things are converging -- the sooner the better.

Re: IDENTIFIERS in Upper Case

[Charles Lindsey]

In <dewar.859783266@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>I agree we are getting there, but there are irritating holdouts (that's
>why I dislike Mike Feldman's choice, it teaches a whole generation of
>Ada programmers to get used to a "non-standard" style). Still, I agree
>that things are converging -- the sooner the better.

Well I LIKE Mike Feldman's choice (upper keywords, lower identifiers - we used
to call it "Upper Case Sropping" - remember?). It has the advantage that it
easily converts to bold-case stropping for published material.

What I think what all are agreed on is that the original choice in the LRM
(lower (or bold) keywords, upper identifiers) was the worst possible
convention.

-- 
Charles H. Lindsey ---------At Home, doing my own thing-------------------------
Email:     chl@clw.cs.man.ac.uk   Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506       Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

Re: IDENTIFIERS in Upper Case

[John English]

Charles Lindsey (chl@clw.cs.man.ac.uk) wrote:
: Well I LIKE Mike Feldman's choice (upper keywords, lower identifiers - we used
: to call it "Upper Case Sropping" - remember?). It has the advantage that it
: easily converts to bold-case stropping for published material.

Yes, I remember it well -- unfortunately for the unfortunates who only had
upper-case-only teletypes to run Algol 68-R on, this translated into "upper
case means lower case, upper case with quotes around means *real* upper case".
(BTW, many thanks for the Informal Introduction... the impact in 1971 for
someone who hadn't noticed a successor to Algol 60 and BNF was mind-blowing;
it was a real turning point for me.)

: What I think what all are agreed on is that the original choice in the LRM
: (lower (or bold) keywords, upper identifiers) was the worst possible
: convention.

Amen.

---------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | fax: (+44) 1273 642405
 University of Brighton    |
---------------------------------------------------------------

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

i<<: What I think what all are agreed on is that the original choice in the LRM
: (lower (or bold) keywords, upper identifiers) was the worst possible
: convention.>>

Nope, all are not agreed on this, it is still my preferred style from an
objective point of view (I know from experience that I can read this style
as well as mixed case, just a matter of getting used to it).

I would have been perfectly happy of the Ada community had generally agreed
to follow the Ada 83 RM recommendiation, but clearly this convention had
enough people reacting as above so that it did not stick.

As I have mentioned before, my perception now is that the GREAT majority of
Ada programmers and Ada programming guidelines prefer mixed case, and I
really think it desirable that this become the essentially dominant style.

I find it a sign of weakness in the Ada community that there are such
scattered opinions on this subject that AQ&S felt compelled not to make
a specific recommendation -- too bad!

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

Charles Lindsey (chl@clw.cs.man.ac.uk) wrote:
: Well I LIKE Mike Feldman's choice (upper keywords, lower identifiers - we used
: to call it "Upper Case Sropping" - remember?). It has the advantage that it
: easily converts to bold-case stropping for published material.


Really that misses the point. Different people will of course have different
tastes (I basically prefer the Ada 83 style of upper case identifiers,
because of the nice property that they are clear in comments).

But I regard my personal tastes, or Charles' personal tastes, or anyone
elses personal tastes as irrelevant. It is MUCH more important for the
community to agree on a common style.

P.S. Charles, Mike's choice is related to Algol-68 more than you think.
Pascal acquired upper the upper case keyword style directly from the
Algol-xx stropping tradition, and Mike follows the Pascal style in an
attempt to make his book more palatable to those professors and instructors
used to teaching Pascal :-)

Re: IDENTIFIERS in Upper Case

[Michael F Brenner]

The worst capitalization scheme is one that involves the programmers
instead of doing it automatically with tools. The second worst is any
capitalization scheme that introduces capital letters to identifiers
or keywords. The correct scheme is to use a typesetting tool to 
emphasize the assertions (preconditions, invariants, and postconditions),
and de-emphasize the identifiers and keywords. An exception is that,
during debugging or during expository text, the typesetting tools 
should be set to give various colors to what you are currently 
describing. For example, in solving the year 2000 problem, the
typesetting tool should color all inter-chip messages containing
2-digit year fields in red, should capitalize all uses of the word
NEW, should color all date processing logig using the Zeller congruence
in blue, and should italicize all preconditions involving date
calculations. When people in authority have personal stylistic
preferences for capitalization, they should identify them as
personal preferences, and not as software engineering. It takes
time to for humans to carry out those preferences, which impacts
the amount of time it takes to change software and to analyze
the impact of those changes.

Re: IDENTIFIERS in Upper Case

[Jeff Burns]

Charlie,

The Software Productivity Consortium Ada 95 Quality and Style Guidelines
may provide some support for your argument, however I didn't notice any
studies cited.

The guideline for capitialization is to "make reserved words and other
elements of the program visually distinct from each other" and
recommends:

	lowercase for all reserved words,

	mixed case for all other identifiers, a capital letter beginning every
word separated by underscores, and

	upper case for abbreviations and acronyms.


The bibliography in the back of the guidelines may get you to something
citing the study you're looking for.

The SPC Ada Guidelines can be found at:

http://sw-eng.falls-church.va.us/AdaIC/docs/style-guide/95style/html/cover.html


Jeff Burns

-----------------------------
Jeff Burns, Director of Marketing
GrammaTech, Inc.
One Hopkins Place
Ithaca, NY  14850
ph: 607-273-7340
fax: 607-273-8752
e-mail:  jeff@grammatech.com
www:  http://www.grammatech.com
Team Ada
==============================
Ada-ASSURED
	LSE
	Style Standards Enforcer
	Browser
	QA Tool
	Code Transformer
"Cure for the Common Code"
==========================

Re: IDENTIFIERS in Upper Case

[Matthew Heaney]

In Guidelines for Enterprise-Wide GUI Design, authors Susan Weinschenk and
Sarah C. Yeo state that "Sentances in all capital letters are 20 percent
more difficult to read than sentences with upper- and lower-case letters. 
Avoid using all caps for large blocks of text." [p. 101]  They later state,
when discussing online help, that one should "Never use all caps, except
for acronyms and initializations.  Words in all caps are harder to read."
[p. 144]

In Usability Engineering, author Jakob Nielsen states that "On alphanumeric
terminals, UPPERCASE TEXT CASE CAN ALSO BE USED TO GET THE USERS'
ATTENTION, but upper case should be used sparingly as it is about 10%
slower to read than mixed-case text." [p. 118-9]

In Principles and Guidelines in Software User Interface Design, author
Deborah J. Mayhew states "Avoid heavy use of all-uppercase letters.  Text
in all uppercase is more difficult to read than text in mixed case.  Tullis
(1988) reviews literature suggesting that people read mixed case text about
13% faster than uppercase.  This is because lowercase letters look more
different from one another than do uppercase letters, making it easier to
determine a word in part by its overall shape." [p. 469]

The Tullis reference is

Screen Design
Thomas S. Tullis
Handbook of Human-Computer Interaction
Martin Helander, ed (Amsterdam: North-Holland, 1988), p. 377-411

Jakob Nielsen writes a regular Interface column for IEEE Software.  He can
be reached at <mailto:jakob.nielsen@sun.com>.

Hope that helps,
Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

iMatthew quotes

<<In Guidelines for Enterprise-Wide GUI Design, authors Susan Weinschenk and
Sarah C. Yeo state that "Sentances in all capital letters are 20 percent
more difficult to read than sentences with upper- and lower-case letters.
Avoid using all caps for large blocks of text." [p. 101]  They later state,
when discussing online help, that one should "Never use all caps, except
for acronyms and initializations.  Words in all caps are harder to read."
[p. 144]>>

I believe that this observation is totally irrelevant to programming
languages. Furthermore, I am not sure it is true even for the environment
that Sarah is talking about. I believe the 20% figure if you are talking
about the difficulty that people have in reading upper case if they are
used to reading normal lower case, but I bet if you tool a control group
of children and reversed the way they were taught that you would see the
20% in the opposite direction.

In the case of programming languages, we ARE talking about people who
are very much used to whatever style they are reading. My guess is that
if you use only people who are very used to reading the style that they
are presented with, you will not see measurable differences. The trouble
is in getting really comparable groups.

When I first started to read Ada code written in mixed-case I found it
MUCH harder to read than the all-upper-case identifier code that I was
used to (at the time I wrote most of my Ada code for Alsys, and that was
our internal convention at the time).

However, now it is exactly the opposite way round for me.

That's why I think it is important that everyone learn to be comfortable
with the same style. The particular choice of style is pretty unimportant.
There are very few objective arguments that favor one style over another,
for a discussion of these see our previous CLA thread on the the subject,
but I think these points are minor compared to the annoyances tha result
from people trying to interact who have different styles.

One of the advantages in C, is that there was a uniform style in C (I
never saw anyone for instance using all upper case identifiers in C
for all purposes, though of course this is perfectly legal in C).

In the Ada 95 world, the use of mixed case identifiers and lower case
keywords is almost universal (I am making that judgment from the code we
have received from thousands of Ada programmers who have sent us code
samples). Yes there are a few variations (probably the majority come
from students influenced by Mike Feldman's "non-standard style" -- that
certainly accounts for at least 50% of the variations -- some of the
rest are old Ada 83 programs written under influence of the implied
recomendations of the old RM (all upper case identifiers).

Since we nearly have a standard in effect, I think the best choice is
to follow that standard and use lower case keywords and mixed case
identifiers. This is one situation where, like driving on one side of
the road, it is more important to have consistency in the community
than to make any one particular choice.

Yes, it can be painful to change over, it certainly was for me, it took
quite a while before I could read mixed case stuff as reliably as the
all upper case identifier style I was used to, but the change over is
worth while (just as Sweden found it was worth while changing to driving
on the right :-)

Re: IDENTIFIERS in Upper Case

[Jerry Petrey]

Matthew Heaney wrote:
> 
> In Guidelines for Enterprise-Wide GUI Design, authors Susan Weinschenk and
> Sarah C. Yeo state that "Sentances in all capital letters are 20 percent
> more difficult to read than sentences with upper- and lower-case letters.
> Avoid using all caps for large blocks of text." [p. 101]  They later state,
> when discussing online help, that one should "Never use all caps, except
> for acronyms and initializations.  Words in all caps are harder to read."
> [p. 144]
> 
> In Usability Engineering, author Jakob Nielsen states that "On alphanumeric
> terminals, UPPERCASE TEXT CASE CAN ALSO BE USED TO GET THE USERS'
> ATTENTION, but upper case should be used sparingly as it is about 10%
> slower to read than mixed-case text." [p. 118-9]
> 
> In Principles and Guidelines in Software User Interface Design, author
> Deborah J. Mayhew states "Avoid heavy use of all-uppercase letters.  Text
> in all uppercase is more difficult to read than text in mixed case.  Tullis
> (1988) reviews literature suggesting that people read mixed case text about
> 13% faster than uppercase.  This is because lowercase letters look more
> different from one another than do uppercase letters, making it easier to
> determine a word in part by its overall shape." [p. 469]
> 

The problem with most of the studies is that they address the effect of
case in normal human reading - we don't read programs in the same way
we read a novel. IMO, programmers can adapt quite well to most any
reasonable case style.  The key thing is separating identifers and
key words to bring out the structure (I still find all uppercase
identifiers
work well for that but the mixed case style seems to be more preferred
today, so I adapt).  There are many other factors that have a much
greater 
influence on readability of programs, e.g. use of white space, a good 
indentation scheme, good choices of names, etc.  Most important is some 
reasonable guidelines within an organization and a consistent use of 
those guidelines.  Expecting the entire Ada (or any other language) 
community to adhere to the same guidelines would be nice but not
realistic
 - conformity within an organization is probably the best we can
achieve.

Jerry



-- 
=====================================================================
== Jerry Petrey                                                    ==
== Consultant Software Engineer - Member Team Ada and Team Forth   ==
==            Rockwell Collins Commercial Avionics Group           ==
==            Melbourne, FL   email: gdp@mlb.cca.rockwell.com      ==
=====================================================================

Re: IDENTIFIERS in Upper Case

[Robert A Duff]

In article <333BCDE9.176C@mlb.cca.rockwell.com>,
Jerry Petrey  <gdp@mlb.cca.rockwell.com> wrote:
>...Expecting the entire Ada (or any other language) 
>community to adhere to the same guidelines would be nice but not
>realistic

I believe the entire Smalltalk community adheres to the same case
conventions.

> - conformity within an organization is probably the best we can
>achieve.

- Bob

Re: IDENTIFIERS in Upper Case

[Robert Dewar]

Jerry Petrey  <gdp@mlb.cca.rockwell.com> wrote:
>...Expecting the entire Ada (or any other language)
>community to adhere to the same guidelines would be nice but not
>realistic

I disagree, there are good counter examples, I already gave two, you
can find others

1. The Ada community generally agrees on the style, if not the amount of
	indentatoin.

2. The C community generally agrees on the style of capitalization

Re: IDENTIFIERS in Upper Case

[Robert A Duff]

In article <mheaney-ya023680002703971831260001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>[useful references about readability and case]

Anybody have any references about readability of different sorts of
fonts?  Colors?

- Bob

Re: IDENTIFIERS in Upper Case

[Tom Moran]

> references about readability of different sorts of
> fonts?  Colors?
ISBN 0-201-10745-7 as previously mentioned

Re: IDENTIFIERS in Upper Case

[William Clodius]

Robert A Duff wrote:
> <snip>
> Anybody have any references about readability of different sorts of
> fonts?  Colors?
> <snip>

This is VERY application specific. Most contexts probably benefit from a
proportional serif font. (Note however, the most commonly available such
font, Times Roman is intended for newspaper work where density is
important, its letters tend to be more narrow with less spacing than
ideal for most applications.) However, I suspect most readers of this
group are not interested in most applications, but are rather interested
in the display of text on monitors for a few selected applications,
e.g., email, and editing code. Serif looses its advantages as resolution
decreases, so sans-serif tends to be preferred for display on monitors,
however some serifs can work well on monitors. Similarly, for the
applications that I suspect are of greatest interest to this group
monospaced fonts work better than proportional fonts. Simple automated
pretty printing almost requires a monospaced font.

I suggest an exampination of the comp.fonts FAQ, (particularly the
section on typography)

http://www.ora.com/homepages/comp.fonts/FAQ.html

the NASA interface component style guide

http://groucho.gsfc.nasa.gov/Code_520/Code_522/Documents/HCI_Guidelines/Interface_Component_Design.html

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: IDENTIFIERS in Upper Case

[Robert A Duff]

In article <333BF206.59E2@lanl.gov>,
William Clodius  <wclodius@lanl.gov> wrote:
>...However, I suspect most readers of this
>group are not interested in most applications, but are rather interested
>in the display of text on monitors for a few selected applications,
>e.g., email, and editing code.

I'm interested in the display of source code, both on the screen, and
printed on paper.  Most people don't use variable-width fonts for source
code, and there's not much tool support for it, as far as I know, which
seems odd to me.  Especially given that variable-width fonts printed in
nice serif fonts is pretty common for documentation and such.

I've seen browsers/editors that put all comments in italics, which seems
very bad to me.

>... Serif looses its advantages as resolution
>decreases, so sans-serif tends to be preferred for display on monitors,
>however some serifs can work well on monitors. Similarly, for the
>applications that I suspect are of greatest interest to this group
>monospaced fonts work better than proportional fonts. Simple automated
>pretty printing almost requires a monospaced font.

Well, certainly "simple" pretty-printing requires a monospaced font, but
why do we insist on such simplicity, when we're willing to put up with
huge amounts of complexity (e.g. LaTeX) in natural-language written
material, to make it look nice?  I mean, why do we argue endlessly about
whether to indent by "3 spaces" or "4 spaces", when we could argue about
whether to indent by ".25 inch" or whatever?

Probably the answer is that fixed-width plain ascii text is much more
portable than anything else.

- Bob

Re: IDENTIFIERS in Upper Case

[Graham C. Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Robert" == Robert Dewar <dewar@merv.cs.nyu.edu> writes:

Robert> even for the environment that Sarah is talking about. I
Robert> believe the 20% figure if you are talking about the difficulty
Robert> that people have in reading upper case if they are used to
Robert> reading normal lower case, but I bet if you tool a control
Robert> group of children and reversed the way they were taught that
Robert> you would see the 20% in the opposite direction.

Interestingly: this isn't necessarily true.  As the jargon file
mentions:

   Decades ago, back in the days when it was the sole supplier of
   long-distance hardcopy transmittal devices, the Teletype
   Corporation was faced with a major design choice.  To shorten code
   lengths and cut complexity in the printing mechanism, it had been
   decided that teletypes would use a monocase font, either ALL UPPER
   or all lower.  The Question Of The Day was therefore, which one to
   choose.  A study was conducted on readability under various
   conditions of bad ribbon, worn print hammers, etc.  Lowercase won;
   it is less dense and has more distinctive letterforms, and is thus
   much easier to read both under ideal conditions and when the
   letters are mangled or partly obscured.

While deformation isn't as important these days, the density and
distinctiveness of lower case characters continue to be important.
Incidentally, the chairman killed the proposal for theological
reasons.

Also: while this is hardly scientific, I was taught upper case first.
Reading text with large amounts of upper case continues to be a pain
in the ass, with one exception; I can read small capitals in small
quantities quite passably.

Robert> One of the advantages in C, is that there was a uniform style
Robert> in C (I never saw anyone for instance using all upper case
Robert> identifiers in C for all purposes, though of course this is
Robert> perfectly legal in C).

Partly this was because C doesn't have real symbolic constants,
instead using a preprocessor.  Using all upper case for preprocessor
constants alerts the reader that something magic is going on, and
diminishes the possibility of the preprocessor stomping all over your
program text.
- -- 
Graham Hughes    http://A-abe.resnet.ucsb.edu/~graham/     MIME & PGP mail OK.
const int PGP_fingerprint = "E9 B7 5F A0 F8 88 9E 1E  7C 62 D9 88 E1 03 29 5B";
   #include <stddisclaim.h>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM0wacSqNPSINiVE5AQH9YwQAjTkd6AfOcFfagKEoATEJ4dFO8uS6Yprm
5m+T0EPR2QrE0SuYZrWMYZ+Kn3N27LO7kx+ZquFe0IjqwJnj0yIImZwcX4dXQ3Jv
kmnnFRcQGHbilQ+woRiVnwGfsZBNi9yTDJN8DROYW5OZkYEhuJBR7W6Ho5g5OHCA
u5Io1ilysWQ=
=r5VQ
-----END PGP SIGNATURE-----