Printable View
OK, as part of quality control for BAE audits we have to write silly documents about the correct naming conventions...
So, I know the naming conventions of Data-Types and controls, however I do not know the industry standards for ado objects...
I always use adoRec for a recordset and adoConn for a connection object...
Don't suppose anyone could shed some light onto this.
Woka
here we use the "rst" prefix for recordsets .... rstResults, rstPricing, etcQuote:
Originally posted by Wokawidget
OK, as part of quality control for BAE audits we have to write silly documents about the correct naming conventions...
So, I know the naming conventions of Data-Types and controls, however I do not know the industry standards for ado objects...
I always use adoRec for a recordset and adoConn for a connection object...
Don't suppose anyone could shed some light onto this.
Woka
and con for connections.... conDB, conDatabase, etc....
then cmd for command objects, cmdSelect, cmdUpdate..... and prm for the parameter object.....
hope that helps...
[edit] IMHO: There's no need to specify ADO.... unless you are using more than one method for connecting to the database (ADO and ODBC) - which seems rediculous, yet understandably possible -- then ADO would seem to be implied.....
Woka,
This is what I could dig up out of a couple of books.
1. Practical Standards for Microsoft Visual Basic gives the Hungarian notation for database objects as:
Prefixes for Database Objects
Database - db eg. dbCustomers
Field (object or collection) - fld eg. fldLastName
Index (object or collection) - idx eg. idxAge
QueryDef - qry eg. qrySalesByRegion
Recordset - rst eg. rstSalesByRegion
Report - rpt eg. rptAnnualSales
TableDef - tbl eg. tblCustomer
2. Programming ADO
In their sample code, they use
Recordset - rs
Connection - cn
Command - cmd
Both books are published by Microsoft Press.
Cheers
Jack
And how do they differentiate this from the Command Button control then?Quote:
Command - cmd
Not that it's a problem, but normally I wouldn't be doing this: cmdAddButton.Excecute.... all commands are scoped local to the sub that's running, and we use n-Teir architecture as a matter of standards.... there are no command buttons in my data access tiers... ;)Quote:
Originally posted by MerrionComputin
And how do they differentiate this from the Command Button control then?
What?! U have no command buttons in your back end tier?! :confused:
Woka
Ok cheers for the varible prefixes.
OK, I am now having to write a "Good Practices" list...So far I have:
- Always manually destroy objects, from their scope when finished with, by setting them to Nothing.
- All database code should be written in the back-end server side components, where applicable.
- Avoid using variants wherever possible.
- Never access methods or properties, from an object, by utilising the default property.
- Passed variables declared in a function should always be declared as ByVal, unless ByRef is specifically required.
- Always use Option Explicit at the top of a module to enforce variable declaration.
- Never use the END command.
- Always set a project to auto-increment its revision number.
- Always declare variables for the scope they are intended for.
I know there are many, many more, but am having a mental block...its just one of those days :(
Woka
Suprisingly some of the develoeprs here do not do any of the above :mad:
Woka
Woka - when you are done with that I'd be interested in a copy....
yea...no probs...
There are one or 2 things I have changed like I have seen varible prefixes on the web that say use lvw for a ListView, and tre for a TreeView...but I have always seen, and used tvw for a TreeView...don't know how much of a problem that causes...
Woka
PS I was joking about the cmd in the back end b 4 anyone sez anything :D
What?
This is my naming convention:
CommandButtons - Command
PictureBoxes - Picture
TextBoxes - Text
Lists - List
ComboBoxes - Combo
TreeViews - TreeView
ListViews - ListView
So I'd have Command1, Command2, etc, Picture1, Picture2, etc. You know, that's the way they're setup as, why change them? VB named them that way and it knows what it's doing.
Anyone who spends time coming up with cute little letters to put in front of them is just wasting their time, and I just don't understand it...
(Kidding, of course...)