I think that ID or id is fine, but definitely not Id or (shudder) iD. I suppose that I tend towards ID, because id is actually a word, and we can't discount some psych major who went into programming using it ;).

Above all, pick one or the other and stick with it.

In any program of mine you open, it will be ID.

userID
customerID
statusID

etc

Eric - I agree, as long as you are consistent!

Chris - I agree that iD looks like a newbie programming variable, but why don't you like Id? It took me a while to get used to, but now I just follow whatever code is already there. I'm sure it's the same for you, as a consultant I get exposed to all sorts of *interesting* coding styles. :)

Speaking for myself, when I see mixed capitalization, I switch from thinking in acronym/abbreviation mode to thinking in word mode. The goal with ID should be to immediately identify that you're referring to the word Identification, as opposed to Id. Of course, a millisecond's thought figures this out, but I see this as a kind of cognitive speed bump.

Not a biggie, but as long as we brought it up...

Good point.

Its sometimes seems funny that we all get so caught up with things like this. But, I too sometimes spend a millisecond more thinking about readable variable/method names then the actual work they are doing. But inconsistencies sometimes bother my simple mind. I prefer ID because when I read it or somebody else reads my code, I want them to say "eye" "dee" not "id" as it sounds in the word "did". Regardless if its real meaning is an abbreviation, I use my case notation to determine how the words(s) will be pronounced/read.

Exactly, especially when most of my applications are database apps. When I see ID I immediately associate that with a primary key / foreign key field in the database. Plus with camel case being so popular, Id looks like a word, not like a key identifier.

First, I'm very pleased that I'm not the only one thinking about such apparently unimportant things.

I'm using "Id" and I justify this by saying that "I" is a reserved prefix for interfaces. To show that, always a lower case letter follows the "I" if it is not an interface like "Id".

Jens has a good point. Perhaps the fact that ID always occurs at the end helps people avoid thinking it is an interface.

Yes, Isomething is an interface. ID at the end is a primary key field.

If you have a property just called Id, I'm going to have to slap you for not typing the few extra characters to make it object-specific.

I've seen database tables where every PK is called Id, and then in the foreign table it's CustomerId. Linking Id to customerId is not immediately intuitive and I consider it to be poor design.

Eric - I completely agree. All the whiney arguments "but you're in the blah table, so you already know it's blahID" suck! I have always used CustomerID, OrderID, etc.

Eric and Darrell - I have to disagree! I rather like naming every primary key in the database ID. It makes perfect sense. Customer.ID, Order.ID, etc. Why would I want to see Customer.CustomerID or Order.OrderID?

If I link link the Order table to the Customer table then it's *very* intuitive to link Order.CustomerID to Customer.ID. What else could it link to?

You don't name every "Name" or "Description" column differently, do you? Naming these like Customer.CustomerName or Order.OrderDescription is just plain silly! Why would you treat the ID any differently?

Oh, by the way, ID or Id - makes no difference to me. Either one is easy to digest.

Actually Mark, I'd have to say that by using objectName, and objectDescription are better for a couple reasons:

1) Name comes across as a reserved word in alot of places, I try to avoid using it.

2) Ok, so let's use:
"From customer Inner Join Orders ON Orders.CustomerID = Customer.ID"

We just saved all of 8 characters worth of typing but our fieldnames don't exactly match. In addition, if we use just "Description" as a field name across all tables, then we're going to have to explicitly type table.Description in all select and where statements for joined tables which adds up to more typing in the long run since just typing Description will raise an ambiguous error.

In addition, if someone is just looking at a dataset generated from a join query, they're going to see a fieldname of "Description"... ok what description? Is it the customer description or the order description? If we're using stored procedures, we're going to have to navigate to the sproc to find out. Even worse is the case of in-line sql where we have to actually hunt the code to find the sql that populates the dataset. Or we have to pull out or nice binder of documentation to find out.

I just feel that in the long run objectValue is a cleaner, more intuitive way to build things and with autocomplete/intellisense there's no real downside to doing it.

All very good points, Eric. I'll have to think on this abit.

<br>
Some short comments. The "children overboard" deceit is being revisited as public servants are stepping forward. Australian government legislates where no government has legislated before - the ongoing growth of the nanny state. John Stuart Mills on freedom of opinion. <br>
<br>
Shorts <br>
A funny blog. Taswegians...