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


I tend to go lower case with keywords, and upper case with database names.
I got into that habit back in the 80s when I was using DEC Rdb/VMS. The
RMU/EXTRACT command would use that case convention when generating DDL.

Add that to the fact that C and its descendants all use lower case for the
reserved words, and the compiler is sensitive to that.

As far as attracting the eye is concerned, Joe Celko makes a good point.
But I find that my eye is attracted to the database names in code when they
are upper cased. And, being the old data-centric fuddy duddy that I am,
that's what I most want to know: what data is this program using (or
mangling)?

However, the opposite convention seems to have prevailed, and I only have
just so much energy to devote to things like fighting the tide.

As far as the original question goes, I like underscore better than
CamelCase, except in URLs!. A URL with an underscore tends to confuse me,
when it's also underlined.

I got into that habit back in the 80s when I was using DEC Rdb/VMS.
<<

I started with FORTRAN, so everything was uppercase on punch cards.
Then I went over to C and evevrything was lowercase. Again this is
due to physical reasons. Punch cards and old line printers did not
have lowercase. Teletypes were a bitch to use and the original C and
UNIX people were two-finger typists who did not like to hold a shift
key.

are upper cased. And, being the old data-centric fuddy duddy that I
am, that's what I most want to know: what data is this program using
(or mangling)? <<

I capitalize schema objects, following the English/German convention
about proper names. It draws the eye and still lets me write a
longer, meaningful name for procs, tables, views, etc.

I still get a kick out of MS telling us how they discovered the
internet, are really interested in it, etc. and then invent a language
called C# so that the octothrope will mess up stuff on the web.

"--CELKO--" <jcelko212 (AT) earthlink (DOT) net> wrote

I started with FAP and FORTRAN on punched cards myself. But I migrated to
DEC machines very quickly, and got used to upper and lower case.

Unlike the bad old teletypes, the early DEC machines used punched paper
tape machines called flexowriters. These things had a standard typewriter
keyboard, including the CapsLock key. So the habits of the later Unix
engineers didn't get started in that culture.

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

Exactly. Upper case makes a word stand out as a unit in itself. This
is certainly desirable in a STOP sign, but not in keywords that, in my
opinion, are meant to be read as part of a larger unit, not as units in
and of themselves.

For example, you wouldn't write this:

Upper case makes a word stand out AS a unit IN itself.

The extra attention drawn to the connecting words makes them look more
like units in and of themselves. Instead, they should be read as part
of a larger structure.
I do have subqueries. In these, SELECT, etc. are the leftmost
non-whitespace words. Same with AND. It's indented, but still
leftmost. Thus upper case doesn't help me scan for it.

The main difference between the two is dropping a line and indenting.
Changing it all to lower case would do nothing, except to make
"color IN ('blue', 'green') look more like one chunk. The upper-case
word in the middle tends to read like a unit in and of itself, so that
the whole thing tends to read like three chunks.

I'm sure that spending enough time reading setences LIKE this one would
train a person TO read things differently, BUT why NOT go WITH what
normal people are ALREADY used to? Normal people read sentences IN
chunks IF you simply go WITH normal capitalization.

I absolutely did notice. The reason I uppercased AND was to make it
clear that it was a unit in and of itself, not a conjunction relating
surrounding words to each other. In SQL I use it as a conjunction,
relating surrounding clauses to each other. I want people to read it as
they normally do, so why use upper case?

I don't understand what problem you encountered that would have been
solved by 3-character tabs. Was it that the lines got longer than 132
columns because of all the tabbing and wrapped around?

I'm not trying to be argumentative in all this. I'm pushing and
prodding to make sure that whatever standard I put forth is defensible.

Yep, and lots of people now believe MS invented SQL just as well.

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

[snipped a bunch of stuff of Mr. Lewis's that I agree with]

With tabs that are too big, yes, it can easily get to very long
lines. Myself, I usually use a maximum 78-character line size. I hit
on three-character indenting, too. I used to do five, and that was
too much. Four was almost it. Three has worked fine. Two would not
be enough, and in my case would be confusing because I indent
continuation lines by one.

It sounds reasonable, but regardless, there will be people who
prefer Something Else. A lot of it is YMMV.

Sincerely,

Gene Wirchenko

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

opinion, are meant to be read as part of a larger unit, not as units
in and of themselves. <<

Wrong, measurably wrong. People read programming code like math than
like text. When I see "AND..." I have an "Announcer" token for a
predicate; my eye can skip to the next "terminator" token (another AND
or whatever) and ingest the predicate as a whole. Ever seen this one?
Read this out loud from a flash card:

Paris
in the
the Spring

If I had written it as "Paris in the the Spring", you would spot the
duplicated "the" in the sentence.

You do read larger units, but you read them in chunks, not one word at
a time. The chunk has to start with a keyword ("Announcer") and
continue to a terminator.

leftmost. Thus upper case doesn't help me scan for it. <<

so you write this:

SELECT a, b, c
FROM Foo
WHERE x IN (
SELECT xx
FROM Bar
WHERE z > 0);

and not this:

SELECT a, b, c
FROM Foo
WHERE x
IN (SELECT xx
FROM Bar
WHERE z > 0);

I find the second much easier to read myself.

make
"color IN ('blue', 'green') look more like one chunk. The upper-case
word in the middle tends to read like a unit in and of itself, so that
the whole thing tends to read like three chunks. <<

Visual chunking is recursive. The indentation and new lines are
important, but once on a line, the reader can skip to the next line or
parse the current line. If there is more than one unit on a line (i.e.
two predicates), then he is confused and has to to do the parse in his
head.

Example:
AND frug <= watusi
AND frug >= monkey

is easier to read and understand than a single line of code with:

AND frug <= watusi AND frug >= monkey

but not as easy as a single line of code with:

AND frug BETWEEN watusi AND monkey

they all have the same logical meaning. The second example is too
visually confusing for people (test: read this code in 1 second and
tell the relationships between frug, watusi and monkey), but it is the
same as the third version with different syntatic sugar!


Again, code is not read like English text. The closest to English
scanning was COBOL -- no surpise there. The worst was C -- no surpise
there, either!

relating surrounding words to each other. <<

BINGO!!

upper case? <<

To annouce a predicate. In English, it can construct a list (cheese
and crackers) as well as join clauses; in SQL it can only annouce a
predicate.

than 132 columns because of all the tabbing and wrapped around? <<

that was part of it and it got MUCH worse as printouts got narrower.
But it goes back further to typewriter rules; one space separates
words, two spaces separate sentences. Thus 3+ spaces or a new line is
a separator.

defensible. <<

Argumentative? I have an on-line persona in some newgroups where I am
the "puppy eating, kitten stomping" bad guy! This is the first time
since I left AIRMICS that I can talk about all those years of SE
research!

In article <nm9zn65cbw0.fsf (AT) scrubbing-bubbles (DOT) mit.edu>, Bruce Lewis wrote:
I personally perfer underscore, but a lot of folks perfer CamelCaps,
with method names & local variables starting with lower case, class
names starting with upper case, global variables being Capitalized, and
constants being all caps.

Problem I have is that I get it all mixed up and end up using
underscores here, CamelCaps there, ALL_CAPS some place else.. especially
when working with multiple languages or switching from one program to
another. (ugh!)

For SQL and HTML I personally perfer ALL_CAPS for the keywords and language
portions, all lowercase for the table and field names. (Especially HTML,
as ALL_CAPS makes it standout apart from any text)

Another thing to consider is whether or not the editors have command
completion, and if it is affected by your choice. If most are using
an editor that treats underscore names as 2 words, you'll probably want
camelcaps.

Still another thing to consider is the language and the target consumer.

If you're working in java land, creatign a framework for people to use,
CamelCaps is the way to go. Other languages like Perl are a bit less
defined, but generally underscores are used. I think ALL CAPS are best
for SQL. (Keeps it standing out in an application, so as not to confuse
it with the rest of the program)

Complex XML seems to be mostly camelcaps.

Suppose you really should be asking your own group what THEY perfer, at
least that way it's not thrust down their throats and they'll appreciate
having some say in the chosen style.

Jamie
--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX