|
Introduction
While writing codes for .NET applications, if you and your team members have some common naming practices, it becomes very useful especially when you're reading your existing codes and modifying your codes in Visual Studio .NET IDE. For naming conventions, I went to the MSDN site, but got so many links which made me a bit frustrated to read all the stuffs by spending couple of hours. However I have used my Microsoft Word application and very quickly written some naming conventions, which can be read and can be used very quickly. My team has found it fruitful; I believe you can find it useful as well.
UI Naming Prefix
| 1 |
Buttons |
btn |
| 2 |
DropDownList |
ddl |
| 3 |
LinkButton |
lnb |
| 4 |
Label |
lbl |
| 5 |
Repeater |
rpr |
| 6 |
DataGrid |
dgd |
| 7 |
CheckBox |
chk |
| 8 |
RadioButton |
rdo |
| 9 |
DataList |
dls |
| 10 |
Image |
img |
| 11 |
TextBox |
txt |
| 12 |
ImageButton |
imb |
| 13 |
HyperLink |
hln |
| 14 |
ListBox |
lst |
| 15 |
Panel |
pnl |
| 16 |
PlaceHolder |
phd |
| 17 |
Calendar |
cnd |
| 18 |
AdRotator |
art |
| 19 |
Table |
tbl |
| 20 |
RequiredFieldValidator |
rfv |
| 21 |
CompareValidator |
cmv |
| 22 |
RangeValidator |
rgv |
| 23 |
RegularExpressionValidator |
rev |
| 24 |
CustomValidator |
csv |
| 25 |
Validation Summary |
vsm |
Casing of Codes
| Name Space Name Case |
NameSpaceName |
| Class Naming Case |
ClassName |
| Method Naming Case |
MethodName |
| Property Naming Case |
PropertyName |
| Enum Case |
EnumName |
| Enum Members |
EnumMemberName |
| Constant Name Case |
ConstantName |
| Local Variable Naming Case |
variableName |
| Param Variable Naming Case |
paramName |
| Region Names |
Region name will be sentence case like this. |
| Code Comments |
Comments will be in general case like this. |
| Private Data |
_privateDataName |
Database
Tables, Relations
| Table Name Prefix |
tbl |
| Table Name Case |
tblTableName |
| Primary Key Name |
PK_tblNameID |
| Foreign Key Name |
FK_'ForeignKeytblName'ID |
Stored Procedure
Stored Procedure Prefix
NOTE: Starting by sp_ prefix causes performance overhead.
CRUD (Create-Read-Update-Delete) Stored Procedures Names
| INSERT |
spr_tblTableName_Insert |
| UPDATE |
spr_tblTableName_Update |
| DELETE |
spr_tblTableName_Delete |
| READ BY PRIMARY KEY |
spr_tblTableName_GetByPrimaryKey |
| READ BY FOREIGN KEY |
spr_tblTableName_GetBy'KeyName' |
| READ ALL |
spr_tblTableName_GetAll |
NOTE 1: This standard groups the stored procedures by table wise cluster, which facilitates changes on a table schema modification in the stored procedure layer.
NOTE 2: For multiple table CRUD operation, use the following example:
INSERT: spr_tblTableName[1_tblTableName2_...tblTableNameN ]_Insert
Other Database Objects
| Function Name Prefix |
fnc_ |
| Trigger Name Prefix |
trg_ |
| Cursor Name Prefix |
crs_ |
| View Name Prefix |
viw_ |
CRUD [Create-Read-Update-Delete] Methods of Data Access Class
Methods
CreateEntityNameUpdateEntityNameDeleteEntityGetAllEntityNameGetEntityNameByIdGetEntityNameBy'KeyName'
NOTE: For DAL/BLL when there is a separate class for each entity, we can exclude the entity name from the method names.
Property
Property Constants
Method Parameter that is Assigned to Property
Conclusion
Any advice or correction for this article will be highly appreciated.
History
- 18th March, 2006: Initial post
| You must Sign In to use this message board. |
|
| | Msgs 1 to 5 of 5 (Total in Forum: 5) (Refresh) | FirstPrevNext |
|
|
 |
|
|
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 | 1.00/5 (1 vote) |
|
|
|
|
|
|
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 (1 vote) |
|
|
|
|
|
|
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 (1 vote) |
|
|
|
|
|
|
|
|
|
 General  News  Question  Answer  Joke  Rant  Admin
|
