RE: CamelCase For Procedures Names
- From: Yong Huang <yong321@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx, Joel.Patterson@xxxxxxxxxxx
- Date: Tue, 22 May 2012 08:08:32 -0700 (PDT)
Correct. If this discussion is limited to Oracle PL/SQL procedure names, you're
absolutely right. I was thinking of CamelCase for token names in programming
code, but not Oracle's PL/SQL.
Yong Huang
--- On Tue, 5/22/12, Joel.Patterson@xxxxxxxxxxx <Joel.Patterson@xxxxxxxxxxx>
wrote:
From: Joel.Patterson@xxxxxxxxxxx <Joel.Patterson@xxxxxxxxxxx>
Subject: RE: CamelCase For Procedures Names
To: yong321@xxxxxxxxx, oracle-l@xxxxxxxxxxxxx
Date: Tuesday, May 22, 2012, 9:58 AM
Once it is in the database, you will end up with GETAREASIZE
Among the other reasons already stated, you will eventually query the data
dictionary, its dependencies perhaps etc. I think that is a major
consideration.
Joel Patterson
Database Administrator
904 727-2546
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Yong Huang
Sent: Tuesday, May 22, 2012 10:52 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: CamelCase For Procedures Names
[Very off-topic!]
I wonder if it's true that people that regularly read Chinese or German (or
ancient Latin) finds CamelCase less offending. In these languages, meaningful
tokens (words in most languages, characters in Chinese) are often concatenated
with no separators. Due to this constant subconscious training, CamelCase
should not be a big issue, because the training is the more rigorous reading of
"nocasewords". But I acknowledge that long CamelCase words are slower to read.
That leads to another point. A procedure name in programming code only (not a
name for an Oracle database object, which is flattened to all capital unless in
double quotes) is usually short. In illustrating the point that a CamelCase
name is hard to read, people use very long names as examples in a
sentence-context. For one, the extra brain power to read a short CamelCase name
is minimal, and the brevity probably has the benefitial effect of focusing your
eyesight into a dot or at least a solid token better than if the string
contains underscores; in fact, the white space above "_" disrupts the image as
a solid token. I believe the brain works better if the string only needs to be
understood as a single solid token, and the shorter the string and the less
white space, the more it becomes solid and closer to a dot.
Secondly, examples citing a long CamelCase string are sentences. The brain
works differently when you're in linear sentence-reading mode. But in
programming code reading mode, you don't literally read linearly, but back and
forth, up and down, repeatedly. A token, as short as possible, as closer to a
dot or solid spot as possible (but not too short to compromise its meaning), is
desired in this context. Because of repeated non-linear reading, GetAreaSize()
may take even less time for the brain to process than get_area_size() every
time your eyes are on it.
Nevertheless, the differences stated above are small. Other rules become more
important, consistent naming convention, etc.
Yong Huang
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
