| You must Sign In to use this message board. |
|
|
 |
|
|
One strength of .NET is that it took emphasis away from object types. Everything is an object, and you are more likely to need naming conventions for classes than for simple types.
The recommendation is now to name your variables to their purpose, e.g. string fileName. Whether you use fileName, FileName, or _filename is the convention issue. Using strFilename or btnClose is outdated and unnecessary.
|
| Sign In·View Thread·PermaLink | 2.33/5 |
|
|
|
|
|
|
I would have to strongly disagree with your database naming conventions.
Tables:
Firstly, there isn't a real benefit with a prefix of 'tbl'. You know it's a table because it is an actual table object within the database. The biggest effect that this might have is having to take off the prefix with your eye to actually read what the tables 'real' name is e.g. TableName.
Are you going to have naming conflicts when not prefixing table names with 'tbl'? I would say probably not. At least not with a normalised database design. The only conflict I would anticipate would be with a table and a view, which might provide an extended look at the table info. Microsoft gets around this one in their CRM software like so:
Their database contains an AccountBase table and an Account view, which combines all the relevant info from the various tables that make up the 'account'. When they need to select an account in it's full form, they query the Account view.
Stored Procedures:
The same goes for stored procedures. MS prefixes there system stored procedures for a functional use, i.e. when a call to a stored procedure begins with sp_, it looks at global/system procedures first. It's not really useful otherwise. You know it's a stored procedure because it's a stored procedure object in the database. And again you'll limit the ease of use when looking at the list of procedures, in Enterprise Manager for example, because you have to remove the prefix as you read the real name.
Therefore I would think that the better convention is to name procedures like so:
TableName_Insert
TableName_Update
TableName_Delete
TableName_SelectAll or TableName_GetAll
TableName_SelectByKeyName or TableName_GetByKeyName
Key Names:
Microsoft has a default convention for naming Keys within SQL Server, and I'd recommend sticking to a similar convention.
Primary Key: PK_TableName
Index / Unique Key: IX_TableName or IX_TableName_ColumnNames
Foreign Key: FK_TableName_ForeignKeyTableName
Otherwise, I think the UI convention is fine. I would prefer names like 'saveButton', 'primaryImage' and 'userDataList' rather than 'btnSave', 'imgPrimary' and 'dlsUser'. That's really just a preference that a development team and/or company can choose to adopt.
The 'Casing of Codes' looks inline with the C# language guidelines, so that's good.
Just thought I needed to shed another opinion on this document - as a lot of junior programmers might read this and take it as a verbatim practice - while it is a convention, and developers need to stick to a convention, I would not consider the database naming as best practice.
Hope that helps
Dave T
PS: I think you have mistake with the repeated 'Primary Key Name' entry.
Primary Key Name: tblNameID
Primary Key Name:'ForeignKeytblName'ID
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
hexy wrote: I would have to strongly disagree with your database naming conventions.
Tables:
Firstly, there isn't a real benefit with a prefix of 'tbl'. You know it's a table because it is an actual table object within the database. The biggest effect that this might have is having to take off the prefix with your eye to actually read what the tables 'real' name is e.g. TableName.
Are you going to have naming conflicts when not prefixing table names with 'tbl'? I would say probably not. At least not with a normalised database design. The only conflict I would anticipate would be with a table and a view, which might provide an extended look at the table info. Microsoft gets around this one in their CRM software like so:
Their database contains an AccountBase table and an Account view, which combines all the relevant info from the various tables that make up the 'account'. When they need to select an account in it's full form, they query the Account view.
Stored Procedures:
The same goes for stored procedures. MS prefixes there system stored procedures for a functional use, i.e. when a call to a stored procedure begins with sp_, it looks at global/system procedures first. It's not really useful otherwise. You know it's a stored procedure because it's a stored procedure object in the database. And again you'll limit the ease of use when looking at the list of procedures, in Enterprise Manager for example, because you have to remove the prefix as you read the real name.
Therefore I would think that the better convention is to name procedures like so:
TableName_Insert
TableName_Update
TableName_Delete
TableName_SelectAll or TableName_GetAll
TableName_SelectByKeyName or TableName_GetByKeyName
Thank you for your message.
First of all the all db object conventions, that i mentioned is from developer perspective. In database you don't really need to have 'tbl'/'spr' prefixes for database tables or stored procedures. But when developing multi-later applications, these prefixes become useful, as generally the code-generator utilities maps db objects to the corresponding logical-coding layer with the name in database server side. As you know there are lots of built-in and custom classes, we are using while coding. Having 'tbl' prefix in the db objects ( and thus in the corresponding logical layers and data containers ) increases the coding productivity by having the opprtunity to identify the db objects easily.
hexy wrote: Key Names:
Microsoft has a default convention for naming Keys within SQL Server, and I'd recommend sticking to a similar convention.
Primary Key: PK_TableName
Index / Unique Key: IX_TableName or IX_TableName_ColumnNames
Foreign Key: FK_TableName_ForeignKeyTableName
Well, thanks for this update.
hexy wrote: Primary Key Name: tblNameIDPrimary Key Name:'ForeignKeytblName'ID
Doh! This is my mistake. Thanks, again. 
Mohammad Ashraful Alam,
.NET Software Engineer
|
| Sign In·View Thread·PermaLink | 2.00/5 |
|
|
|
|
|
|
joycsc wrote: First of all the all db object conventions, that i mentioned is from developer perspective. In database you don't really need to have 'tbl'/'spr' prefixes for database tables or stored procedures. But when developing multi-later applications, these prefixes become useful, as generally the code-generator utilities maps db objects to the corresponding logical-coding layer with the name in database server side. As you know there are lots of built-in and custom classes, we are using while coding. Having 'tbl' prefix in the db objects ( and thus in the corresponding logical layers and data containers ) increases the coding productivity by having the opprtunity to identify the db objects easily.
I would not use code-generation as a justification for hungarian notation (prefixes) on database objects. There is plenty of information within the database for a code-generator to determine whether it's dealing with a table or procedure (sysobjects for instance). So this reasoning might be specific to your specific tools.
Also, rather than dealing with some bizarrely named object to identify object types, I would encourage a good design (namespaces, inheritance, etc) in the business library/generated code.
As a rough example, one class per table at the root of the business logic library (each could inherit from a common "table base class"):
MyApp.BusinessLogic.TableName
Then perhaps static classes to wrap the stored procedures within a Data or DAL namespace:
MyApp.BusinessLogic.Data.TableName.SelectAll
MyApp.BusinessLogic.Data.TableName.SelectByKey
MyApp.BusinessLogic.Data.TableName.Insert
It gives a more structured approach to seperating out the levels and avoids the hungarian notation 
Cheers
Dave T
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
|
|
|
