RE: CamelCase For Procedures Names
- From: "Kenneth Naim" <kennethnaim@xxxxxxxxx>
- To: <JChirco@xxxxxxxxxx>, <Joel.Patterson@xxxxxxxxxxx>, "'oracle Freelists'" <Oracle-L@xxxxxxxxxxxxx>
- Date: Tue, 22 May 2012 13:32:48 -0400
I agree and have used this method for years and find it much more readable.
Similar to dba_tables, dba_tab_columns etc.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jeff Chirco
Sent: Monday, May 21, 2012 3:39 PM
To: Joel.Patterson@xxxxxxxxxxx; oracle Freelists
Subject: RE: CamelCase For Procedures Names
Really, I feel table names should be plural. I believe Steve Feuerstein
recommends this too. It is a Table of EMPLOYEES not a Table of EMPLOYEE.
From: Joel.Patterson@xxxxxxxxxxx [mailto:Joel.Patterson@xxxxxxxxxxx]
Sent: Monday, May 21, 2012 11:44 AM
To: michaeljmoore@xxxxxxxxx
Cc: andy@xxxxxxxxxxxxxxx; kennethnaim@xxxxxxxxx; Jeff Chirco;
Oracle-L@xxxxxxxxxxxxx
Subject: RE: CamelCase For Procedures Names
I certainly agree about the prefixes - and the suffices for that matter. I
just made an exception for tables - but optional. Something not mentioned,
but not optional IMHO is to make table names singular. It is the EMPLOYEE
table, not EMPLOYEES.
Joel Patterson
Database Administrator
904 727-2546
From: Michael Moore
[mailto:michaeljmoore@xxxxxxxxx]<mailto:[mailto:michaeljmoore@xxxxxxxxx]>
Sent: Monday, May 21, 2012 11:47 AM
To: Patterson, Joel
Cc: andy@xxxxxxxxxxxxxxx<mailto:andy@xxxxxxxxxxxxxxx>;
kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx>;
JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx>;
Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx>
Subject: Re: CamelCase For Procedures Names
I think the advantages of having a standard prefix outweigh the
disadvantages. One such advantage I found unexpectedly. We start all of out
table names with T, like TVENDOR. The big advantage comes in verbal
conversation. When, in a design meeting, somebody says 'tee-vendor' , it is
immediately clear that they are talking about the database table, and not a
person that sells things. Of course you could say, 'the vendor table', but
when the names of tables are mentioned thousands of times over the course of
a month, the savings in time and effort adds up. Other advantages may be
specific to your shop. I.e do you use Perforce? Do you produce reports that
contain a mishmash of dictionary object types. One suggestion I would make
however is not to use a _ . ie. not T_VENDOR, but TVENDOR. With only 30
characters, every character counts. Sometimes you will want to combine
names, for example suppose you want at table that maps vendors to customers.
You might want to call it Tcustom er_vendor_map. Then suppose you want to
name an index for this table; tcustomer_vendor_map_ix. In this particular
example still did not push beyond the 30 character limit but many table
names will be more than 6 to 8 characters to start with. This might seem
like a trivial problem, but it can be very annoying when you are trying to
follow the index naming standard and somebody has created a table name
that's alerady 30 characters long. Use abbreviations where possible. Instead
of Tbilling_revenue_stage, use tbil_rev_stg. Maybe the first time somebody
looks at it, they won't know what it means, but some poor schmuck like me is
going to have to type that table name a thousand times over the next 5
years, so keep it short.
IMHO.
Mike
On Mon, May 21, 2012 at 6:00 AM,
<Joel.Patterson@xxxxxxxxxxx<mailto:Joel.Patterson@xxxxxxxxxxx>> wrote:
I like the example, it pretty much says it all (43 chars though).
What about suffixes or prefixes like R_for_procedures (or _R), or P_for
packages, I did not catch Steve mentioning Packages and Package declarations
in the paper? (btw I don't believe tables need a prefix or suffix).
I do like what Steve says about avoiding 'get' with regards to a function.
Joel Patterson
Database Administrator
904 727-2546<tel:904%20727-2546>
-----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 Andy Klock
Sent: Friday, May 18, 2012 9:11 PM
To: kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx>
Cc: JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx>; oracle Freelists
Subject: Re: CamelCase For Procedures Names
The most important thing is consistency by a defined coding standard that
everyone must follow. I don't even think it's because it makes the code
more readable (though it does) but more because it saves so much time not
having to think about what and how to call stuff.
Developers should spend more time on the actual logic than whether or not to
use CamelCaseWhichIsAnnoyingAsHellWithLongNames or easy_to_read_names.
An old friend and colleague (who I know is a lurker here:) turned our old
team onto a document very much like this:
http://www.toadworld.com/Portals/0/stevenf/Naming%20Conventions%20and%20Codi
ng%20Standards.pdf
Make amendments to fit your taste. For me it made all the difference in the
world.
Andy
> -----Original Message-----
> From:
> oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@freelists
> .org>]
> 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.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
-----
Checked by AVG - www.avg.com
Version: 2012.0.2176 / Virus Database: 2425/5013 - Release Date: 05/21/12
-----
Checked by AVG - www.avg.com
Version: 2012.0.2176 / Virus Database: 2425/5015 - Release Date: 05/22/12
--
//www.freelists.org/webpage/oracle-l
Other related posts:
