I'm trying to determine if a local variable in C# should be named "corpID" or "corpId".
See the difference? Should the "d" to be upper case or lower case?
Consider this one also:
customerPK vs. customerPk
It matters more if another word is added the end. Like this:
customerPKField vs. customerPkField
See my delima? Is there a widely adopted way to handle this?
Lower case every time. It will look really odd sometimes, but it beats the alternative: your creating comparatively more oddities/inconsistencies by making the decision all the time about whether or not to capitalize.
This is a duplicate of http://stackoverflow.com/questions/596062/net-naming-convention-for-id-anything-identification-capitalization
From the accepted answer there,
"Id" is an abbreviation for Identifier, so it should stay pascal cased.
For corpId, my personal preference is corporationId. You've spelled out the entire word, so it won't get confused with the "Id" part.
However, you should decide what you like better and be consistent. If you're on a team, but consistent with the team.
The Capitalization Conventions in the Guidelines for Names says:
The two abbreviations that can be used in identifiers are ID and OK. In Pascal-cased identifiers they should appear as Id, and Ok. If used as the first word in a camel-cased identifier, they should appear as id and ok, respectively.
This would suggest that corpId is correct, if this is part of the public interface of a class or struct.
However, if this is a parameter being passed into a method, then camel casing rules apply, and:
Do capitalize both characters of two-character acronyms, except the first word of a camel-cased identifier.
So, as a parameter name, you'd use corpID.
(Personally, I find this odd, and always use corpId, but this is the actual official guideline...)
From http://msdn.microsoft.com/en-us/library/ms229043.aspx:
`Note:
The two abbreviations that can be used in identifiers are ID and OK. In Pascal-cased identifiers they should appear as Id, and Ok. If used as the first word in a camel-cased identifier, they should appear as id and ok, respectively.`
This really falls more into company standards. Within my team it is acceptable, and preferred that abbreviations (such as ID) remain the same case all the way through. So for instance if you have idCard or cardID it always remains with the same casing. But some groups believe it should be only the first letter for readability. All comes to personal preference...
The advantage of systematically returning to lowercase with each word or even acronym or abbreviations within an identifier is that it makes word separation and hence identifier reading easier.
The drawback of doing so it that said acronyms and abbreviations, in particular when they are short like IO or ID may look a bit odd at first.
My personal preference is to only UpperCase the initial letter of each word, acronym, abbreviation (except for the very first word, in case of camelCasing). That is
CorpId
EmployeeSsn
PkIndex
MiscDataList
No matter what you opt for, what really matters is that it should be consistent; companies often have conventions they like the programmers to follow in the area of naming as well as other practices. The general trend is to avoid abbreviations, except the most widely known and accepted ones (say ID, for sure and SSN in the context of an accounting/PR application).
Choose whatever you like, but be consistent. This is one of the cases where taking a "bad" decision is always better than taking no decision and over-discuss this thing.
I'd use Id and Pk for names. Actually there is a topic about capitalization on MSDN http://msdn.microsoft.com/en-us/library/ms229043.aspx
The .NET naming convention allows for two-character abbreviations like ID.
The most important thing is to keep you naming scheme consistent across the whole project/solution. Don't use Id here and PK there, or even worse, mix Pk and PK.
Now since I always write Id I also keep all other abbreviations in strict .NET style: Pk
Edit:
Casing of acronyms depends on the length of the acronym. All acronyms are at least two characters long. For the purposes of these guidelines, if an acronym is exactly two characters, it is considered a short acronym. An acronym of three or more characters is a long acronym.
The following guidelines specify the proper casing for short and long acronyms. The identifier casing rules take precedence over acronym casing rules.
Do capitalize both characters of two-character acronyms, except the first word of a camel-cased identifier.
A property named DBRate is an example of a short acronym (DB) used as the first word of a Pascal-cased identifier. A parameter named ioChannel is an example of a short acronym (IO) used as the first word of a camel-cased identifier.
Do capitalize only the first character of acronyms with three or more characters, except the first word of a camel-cased identifier.
A class named XmlWriter is an example of a long acronym used as the first word of a Pascal-cased identifier. A parameter named htmlReader is an example of a long acronym used as the first word of a camel-cased identifier.
Do not capitalize any of the characters of any acronyms, whatever their length, at the beginning of a camel-cased identifier.
A parameter named xmlStream is an example of a long acronym (xml) used as the first word of a camel-cased identifier. A parameter named dbServerName is an example of a short acronym (db) used as the first word of a camel-cased identifier.
In the naming recommendations for .NET it says that two character acronyms should be upper case while acronyms with three letters or more would be pascal/camel case.
That would give you customerPK and customerPKField as PK is an acronym, but with Id/ID that is harder. Is it really an acronym? For I-Dentity? I always use Id rather than ID.
Yes, there are guidelines for naming. See http://msdn.microsoft.com/en-us/library/ms229002.aspx in general, and http://msdn.microsoft.com/en-us/library/ms229043.aspx for capitalization.
The answer to your particular "corpID" question is most likely "corporateId", depending on exactly what that "corp" is meant to represent.
I'd say, whatever convention you choose, don't make this into some religious thing. It's just not worth bothering... (I'm not saying that coding guidelines are useless, just this particular issue I consider not very important).
It's not that corporationId is any clearer or less clear than corporationID, is it?