Code convention

Hot Topic

How to find a System Tray Process
Running native code on C#
BreakPoint now working
Property Storage
Open MultiPage Image?
How can I edit the Controls' properties while the app is running?
DLL Returns object {string[]}
Microsoft .NET Security Warning
How to catch exception from third party component??
GridView doesn't show

Visual C#

Help with retaining text box values
Does C# 2005 support coding RS232 serial communications?
C# Or C++ .net?
database connection string
Installing a c# app with .net framework
EnumBuilder
listBox - System.NullReferenceException
Retreive local computer's acount password?
How do I convert a 4-byte array (of type bytes) into a 4-byte floating-point?
Allow/Disallow download managers to download?

Code convention

Hello,

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


Thanks,

Itzik Paz.

Answer this question

Code convention

  • dbdog

    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.

    -Neil

  • Bloom326984

    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.

     

     

  • mNilysg

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

    Best Regards,

    Rizwan



  • Martin Lynch

    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.

  • Tabas

    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.
  • Code convention
Answer this question