Re: CamelCase For Procedures Names
- From: Michael Moore <michaeljmoore@xxxxxxxxx>
- To: Joel.Patterson@xxxxxxxxxxx
- Date: Mon, 21 May 2012 08:47:14 -0700
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 Tcustomer_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> 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
> -----Original Message-----
> From: 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
> Cc: 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%20Coding%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]
> > 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
Other related posts:
