RE: [QUARANTINE] Re: CamelCase For Procedures Names

  • From: Jeff Chirco <JChirco@xxxxxxxxxx>
  • To: Michael Moore <michaeljmoore@xxxxxxxxx>, "mwf@xxxxxxxx" <mwf@xxxxxxxx>
  • Date: Mon, 21 May 2012 15:21:28 +0000

I wish I could get the .Net developers out of the database all together but 
that wont happen.
From: Michael Moore [mailto:michaeljmoore@xxxxxxxxx]
Sent: Saturday, May 19, 2012 2:51 PM
To: mwf@xxxxxxxx
Cc: kennethnaim@xxxxxxxxx; Jeff Chirco; oracle Freelists
Subject: [QUARANTINE] Re: CamelCase For Procedures Names
Importance: Low

CamelCase in PL/SQL. That's idiotic.
Mike
On Sat, May 19, 2012 at 1:13 PM, Mark W. Farnham 
<mwf@xxxxxxxx<mailto:mwf@xxxxxxxx>> wrote:
/religious war warning on

a) I hate camel case
       I hate to read it
       I hate to type it
            If you make me read it or type it I have to exert effort to not
hate you. Since I've renounced hate and violence I'll make that effort, but
it will annoy me.
b) Camel case contributes to carpal tunnel syndrome. Minimizing having to
hit the shift key is good.
c) Typing camel case is slower than typing all lower case.
d) Cary recalls some study that concluded that underbars cause hitches in
the read pattern or something. I've always thought that report was about old
line printers where even a slightly worn ribbon tended to do a bad job of
printing underbars on the "high speed" printers of the day. I don't really
know. Since I like underbars and see them a lot, I do not believe it hinders
me. Since I know the question, that will be very difficult to test.
e) Yes, you have to hit a shift to type _ too. But it can be a consistent
cross hand shift, not like shifting for pseudo random patterns of the 26
characters of the alphabet.
f) Long variable names that read like a whole sentence are over rated for
clarity.
g)Long variable names make things actually much bigger in storage and that
can have a real cost.
h)Really short variable names that do not fit the purpose can also be
cryptic and misleading.
i)Using really short things like a1, b2, m3, n4, and x, y, z can be very
clear for some purposes such as math routine utility programs (i and j for
loop counters anyone?).
j) Adopt something that leans toward short is good but clear is essential
and you will end up happier.

religious war warning off/

mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx> 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>]
On Behalf Of Kenneth Naim
Sent: Friday, May 18, 2012 6:06 PM
To: JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx>; 'oracle Freelists'
Subject: RE: CamelCase For Procedures Names

I prefer lowercase myself as it is much more readable, using quotes all the
time for mixed case makes developing more tedious and like you said isn't
common in the database world. I also think it is a good reminder for the
.net developers that they are no longer writing .net and need to adapt to
how pl/sql should be written. There are many differences that they will have
to adopt and it should start with naming. "The line will be drawn here, no
further!"

Ken

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx> 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>]
On Behalf Of Jeff Chirco
Sent: Friday, May 18, 2012 5:39 PM
To: oracle Freelists
Subject: CamelCase For Procedures Names

I am settling a debate about allowing CamelCase procedure names within a
package.
For example
Procedure GetOpenProjects()
Or
Procedure get_open_projects()
I am particularly against it and would rather have everything to be
lowercase and separated by an underscore but some of my developers, mainly
the ones coming from the .Net world prefer it.  What are your thoughts?  Do
you allow it or not?  I am the DBA so I have the ultimate decision but I
trying to see if I am not being reasonable.  In the .Net world it makes
sense but in the database world nothing is case sensitive so I don't feel
that it is a good use.

--
//www.freelists.org/webpage/oracle-l


-----

Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.2176 / Virus Database: 2425/5007 - Release Date: 05/18/12

-----

Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.2176 / Virus Database: 2425/5008 - Release Date: 05/18/12

--
//www.freelists.org/webpage/oracle-l

--
//www.freelists.org/webpage/oracle-l



--
//www.freelists.org/webpage/oracle-l


Other related posts: