IAmSeekingCitationsForStudiesThatEitherConfirmOrRe futeMy
PersonalOpinionThatUnderscoresAreMoreReadableThanC amelCase.

I_am_seeking_citations_for_studies_that_either_con firm_or_refute_my
personal_opinion_that_underscores_are_more_readabl e_than_CamelCase.

Bruce Lewis wrote:

Why do you care? Use whichever you like. A better thing to worry about
is having meaningful identifiers that aren't too long. Then it doesn't
matter much.



Brian Rodenborn

Bruce Lewis wrote:

Try using the space bar next time, Bruce.

It's there, it's big. If you want it to transmit the
code for "underscore" there are system specific ways
to do that on most systems.

Whether or not your recipeints will like it
is another story.


--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

Bruce Lewis <brlspam (AT) yahoo (DOT) com> wrote:

Obviously, the underscore version is more readable than the
CamelCase, because there is more of it to read. (<BigEvilGrin> or
<big_evil_grin> as you prefer)

This is a YMMV issue. I prefer CamelCase in variable names or no
capitalisation at all. (The latter is based on the consideration that
if the name is too long to parse easily, it is probably too long
period.)

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

I'm pretty sure Bruce is referring to database identifiers, in which case the spaceBar is strictlyVerboten.

--
Paul Horan
Sr. Architect
VCI Springfield, MA
www.vcisolutions.com

"Nick Landsberg" <SPAMhukolauTRAP (AT) SPAMworldnetTRAP (DOT) att.net> wrote

Default User <first.last (AT) boeing (DOT) com.invalid> writes:

I'm writing a style guide for my development group. Whichever I like
happens to be underscores, but I want to be sure. Although it looks
like a significant readability difference to me, another developer says
that it doesn't to him, and additionally that his experience with the
underscore standard is that confusion arises about whether something is
a compound word or needs an underscore separator, inconsistencies like
FY99 vs FY_99 come up. If I'm going to foist these difficulties on the
group, I'd like studies to back up my opinion. If studies refute my
opinion, I may just go with CamelCase to avoid the inconsistencies.

"Default User" <first.last (AT) boeing (DOT) com.invalid> wrote

I prefer HumpNotation as I find it faster to type and easy to read. It's
also shorter.

SEI studies in the early 1980's and some stuff at the University of
Maryland; Ben Schneidermann might be of some help. I used to work for
AIRMICS back in those days and we had a ton of graduate thesis papers
on this kind of thing.

The big test was to put in some bugs, format the code different ways
and see how long it took to find the bugs. The results were a savings
of 8-12% in the cost of maintaining the code overall.

As I recall, underscore was clearly better than CamelCase, UPPERCASE
and nospacesatall. Uppercase the reserved words, lowercase user
created names. Do not indent more than 3 spaces. Use monospace fonts,
so the eye can follow code vertically. Start each line with a
keyword. Use the regular rules of punctuation where possible. Use the
normal rules that typesetters have for readability where possible.
Etc.

The big danger with underscores was putting two of them together in a
name, so you made that illegal and enforced it with a pretty printer.
The problem in those days with CamelCase was the lack of lowercase
letters on mainframes and their peripherals; kiss your portability
goodbye!

jcelko212 (AT) earthlink (DOT) net (--CELKO--) writes:

This is one I've never quite understood. I tend to go with lower case,
e.g.

select color, count(*) as people
from Favorite_Colors
where color in ('blue', 'green')

The only keywords I would expect to scan for while debugging are SELECT,
FROM and WHILE, but those are all along the left margin, so capitalizing
them isn't useful. I wouldn't scan for AS or IN, so why make them stand
out? Most SQL keywords are simple English words that take their usual
English meaning, so they don't easily get confused with user-defined
identifiers.

This one I don't get either. What's wrong with

select color, count(*) as people
from Favorite_Colors
where color in ('blue', 'green')
and name like 'J*'
order by color

I find the eight-character tab for the AND line quite clear.

If I understand this correctly, I'm following it above where I put no
space before the comma, but do put a space afterward. "Where possible"
refers to the fact that I can't put the comma inside the preceding quote
as a typesetter would.

Thanks for the pointers on the underscore/CamelCase issue.

This is the "Newspaper headline" rule from typography. Readers see
the UPPERCASE word as a unit in itself rather than actually read it.
Think about a STOP sign in lowercase; it does not work fast enough.
But a sign with STUP will work because it is recognized as a unit. In
a programming language, the reserved words are never misspelt if the
program compiled properly.

Another piece of typography is a river -- vertical white space in the
middle of text that is very undesirable in text, but a boon in
programming:

SELECT||color, COUNT(*) AS people
FROM||Favorite_Colors
WHERE||color IN ('blue', 'green')
AND||name LIKE 'J*';


The reason it hurts text is that the eye tends to "flow down river"
and not left to right. The reason it helps code is that the eye tends
to grab the river and relate the clauses as a whole.

margin, so capitalizing them isn't useful. <<

You have no subqueries? No predicates AND-ed together?

meaning, so they don't easily get confused with user-defined
identifiers. <<

It is not getting them confused with identifiers; it is seeing them as
a structure which frame user-defined identifiers. Experienced
programmers do not read code like test (left to right, top to bottom);
they read it in chunks, usually clauses or subclauses in modern
languages. Example:

1) where color in ('blue', 'green') and name like 'J*'
2) WHERE color IN ('blue', 'green')
AND name LIKE 'J*';

The second example has a keyword at the beginning of each chunk.


Did you notice that you uppercased AND, to make your sentence readable
?

Eye movement. The average English word is five letters, so we expect
to see a word in a longer gap. The 8-space tab is a mechanical
accident from the first teletypes that got carried over; see also the
80-column screen from the 80-column punchcard. The tab indentation
was a real maintenance killer when we had crappy printers and 132
column green-bar paper; alignment was awful, so we had to use a
special ruler to follow code.

possible" refers to the fact that I can't put the comma inside the
preceding quote as a typesetter would. <<

Yep! The space after the comma is really important in SQL. Modern
laser printers andf good fonts make periods and commas look too much
alike so you are not sure if you have a list element or a qualified
name.

But the Brits use different rules about quotes. We started putting
punctuation marks inside quotes to physically protect them. The type
available in Colonial America was of poor quality and the thin pieces
would break.

Want another one? There is a test for brain injury where you are
shown a deck of flash cards with the names of colors printed in
various colors (i.e. the word "RED" in green ink). The tester flips a
card and calls out "word" or "color" and you reply. This tests how
fast you can switch sides of your brain and it stays pretty constant
most of your life, unless something has happened to your brain.
Training does not help.

Those fancy programming editors with a zillion colors for every kind
of syntax element in a language are a screaming "pain in the brain"
for those of us who are strongly analytical, language users (left
brained). They slow me to about 1/3 of my normal speed and give me
headaches. Other people swear by them.