Itzik Paz


As a development team leader I have a difficulty to exlpain logically the following case:
We write code in c#, designing classes that will hold data(stored in SQL DB).

Let's say for example a class which will hold the DB user information.
The DB table will hold the followin columns: [UserID],[UserFirstName],[UserLastName],etc...

Now the class will hold the following properties: UserId,FirstName,LastName.

The question is why using "UserId"(as the property name) and not just "ID" like any other native objects in the .net framework


Itzik Paz.

Re: Visual C# General Code convention


There is not a problem in using ID but just for better readability userID will be good...

Best Regards,


Re: Visual C# General Code convention

Paul Louth

UserId is more descriptive of what the field actually is.  Id is short for Identifier, and could be an identifier for anything.  UserId explicitly states its purpose. 

Also, if your class is a direct representation of a row in your Users table then you should call it UserId in the class as well, because then there's less likely to be any confusion further down the line.



Re: Visual C# General Code convention


I always name the properties the same as column names in my table. About your question, you can of course name the property Id, nobody stops you. It is in fact much easier to use that. By the way UserID will give you a warning from FxCop that you should fix capitalisation. Better is to use UserId. But this is all about .NET. When you work on database, writing stored procedures, then names like UserId, and not just Id comes in play, and it will help discovering which column is that. When you make joins with other tables, and all of them have keys named Id, you will not know which column to which table belongs.

Re: Visual C# General Code convention


Over the lifetime of a large project, we did what amounted to an informal experiment in naming conventions for the situation in the OP.

My opinion of the result is that using a generic "ID" is good in that you never have to worry about what the ID (etc.) field is named.

However, using the "xxxxID" (etc.) method is even better, because it:

1) Provides better coordination and self-documentation between parts of the project contained in different technologies (e.g. C#, SQL, XML).

2) Automatically removed any ambiguity when a data structure had to contain more than one ID (e.g. a linking table, or class that contained IDs from two tables).

The main case where using a common name like "ID" might still be good is where the "ID" represents a kind of "virtual interface" working between technologies, where the details are to be hidden.


Re: Visual C# General Code convention

Itzik Paz

Thanks Folks.

All your answers helped me developing a discussion within my team.
I totally agree with Neil about the self-documentation and the ambiguity issues.

Thanks again,
Itzik Paz.