This content has been marked as final. Show 51 replies
This is regarding mostly to SQL not to PL/SQL.
hungarian notation with types, eg: t_datatype,c_cursor, r_row, f_funcation, t_table,
I'm still wondering what the added benefit of that naming scheme would be.
I was thinking a while about it. I noticed that I still use myself a lot of "type nameings" where the type is somehow included in the object name. I seriously consider changing such habits.
I think this dates back to the days of the oracle designer (8 years ago in my case), where certain objects where generated with certian naming styles.
Primary Key Constraint => table_pk
Unique key Constraint => table_uk
foreign key Constraint => sourcetable_targettable_column_fk
Sequence => tableSeq or seq_table
Trigger => TRG_tablealias_BRIU (BRIU meaning before row insert update)
Do such nameing styles really help to develop better applications? I'm not so sure anymore. However there is more to consider.
On the logical level we have one entity, e.g. PERSON. On the database layer this one entity might resolve to various objects. The table (PERSONS), the identifier (PERS_PK), the sequence (PERS_SEQ), etc. Because all objects share the same name (=same entity) there is some need to distingish one object from the other. This is especially true where there is only one object of this type (usually) for the entity. Primary identifier and sequence are such objects. In this case adding the type reveals some very useful information.
On the other hand I do name my indexes like tablealias_columnname_ix or IX_tablealias_columnname. I can't see any advantage of that anymore. Problem is what name to choose for an index.
In the trigger example the reason was that oracle designer mixed trigger code with functions and procedures (called module logic if I remember correctly). It was helpful to start the trigger with some name like TRG to have all trigger logic at the same place. When I think about that, I hate to apply some nameing standard because some tool forces me to do so (even thou Oracle Designer was an exellent case tool back in those days).
I'm still miffed at losing the argument with my bossOne reason I would use prefixes is to distinguish between products in the same schema. For example CMS_ for a content management system that could be used by several customers, where the schema represents a customer.
that all table names in the ABC schema will be
prefixed ABC_ e.g. ABC_PRODUCT_TYPE, ABC_PERSON, all
tables in the DEF schema will be prefixed DEF_ and so
PK for example can be useful if you get an exception, but trg is only redundant because you can't execute triggers manually and if you get an error message it usually states that the problem is a trigger. Of course I forgot about Designer, the naming schema there does have its irks.
Message was edited by:
> My problem with CamelCase in PL/SQL is that PL/SQL variable names aren't
Nor is Pascal case sensitive. And if you want to see how a robust, mature and sensible Pascal coding standard looks like, have a look at that of Borland's - initially developed in the early 80's for Turbo Pascal.. and continually improved to cater for new technologies (like o-o) in the Pascal language for close now to 30 years.
PL is very close to Pascal. You read and understand PL? You will be able to read and understand and even code in Pascal.
So when I see these really stupid PL "standards" of prefixing variables and parameters, using uppercase for reserved words and so on.. it really rubs me the wrong way.
And yes, it is stupid. I have 30 years of standards for an almost an identical language backing me up. And I have yet to see anyone countering that with a sensible argument as to why an almost identical language warrants established standards to be violated.
> What I can't stand is database object names relying on CamelCase in order
to be readable when they are actually stored in uppercase
Exactly. And I think that is what causes the confusion William. People see PL and think SQL standards and conventions.
No. PL is a formal declarative procedural language. Just like Pascal. Just like C.
There is no reason to enforce standards used for SQL (something very foreign in comparison) on PL.
There is every reason for treating these two languages differently standard's wise.. and using common sense when coding a single source code unit that uses both languages.
As I said - the major problem is one of scope. Making sure that SQL language objects (such as column names) do not conflict with PL language objects (such as variable names).
And there are established and sensible ways to deal with language scope. Mucking about with language standards ain't one of them.
I seem to recall that you like to prefix your type definitions with T. Care to discuss why this is better than the things you tend to criticize?
> I seem to recall that you like to prefix your type definitions with T.
Yes. This was introduced by Borland when their Pascal compiler started to support o-o Pascal language extensions.
As Pascal is not case sensitive, you cannot use case to differentiate between a class type and an object of that class (as in C++). The standard was introduced to prefix type definitions using T. A simple and easy to remember and use standard - as the data type itself is not identified via a prefix. You simply use it to differentiate between the type definition and the variable/object definition.
In the Borland Delphi/Kylix o-o hierarchy you will for example get the abstract class TCustomButton that you will then subclass into something like TAnimatedButton - where the variable can then be called animatedButton.
> Care to discuss why this is better than the things you tend to criticize?
Yeah.. seems like I tend to this a lot these days... Sorry...
I've written a lot of Pascal code. These days I write mostly lots of PL/SQL code.
And as PL is so close to Pascal syntactically and structurally, I get very frustrated seeing PL code every single day (here and in the office) that violates the standards that I've used since the 80's - standards set by very knowledgeable and experience people. Standards that matured by actual usage and application in real-world programming since the 80's.
These very same core standards you will find today in .Net. And in Java. I do not see PL/SQL as so "special" as to merit violating these standards.
And I was seduced by the Dark Side too. I've also used the "common" PL/SQL standards of prefixing variables and uppercasing reserved words. Grew to hate coding in PL/SQL as it made no sense. So I tried to modified it by using suffixing for example. It did not really solve the root problem of scope. Finally (after many years of coding PL/SQL) I stopped being frustrated by trying to conform to these asine "standards" for PL/SQL.
PL/SQL is not special and different. It is just another programming language. And despite what some PL/SQL experts say, the core standards we use for Pascal, C/C++, .Net, Java and so on, also apply to PL/SQL.
And my code looks and reads and maintains a hell of a lot better since I stopped with these so-called PL/SQL standards and simply use the common and core set of standards I've used in Pascal and in C/C++ and other languages.
Thanks for those insights. I may not agree with them, but I get your point of view.
Hmmppff... You only say that because you want me to pay for the next round of beers..