What is the best practice for naming data keys?

I've been wondering whether there is any 'best practice' of naming data keys, and, perhaps 开发者_如何转开发more importantly, whether there is any standard method of naming these entries.

Most formats, that I have seen, are akin to or variations of the following:

• datakeyone
• dataKeyOne
• data-key-one
• data_key_one

But is there any standard or recommended method, and if not (or if there are multiple) what are the pros and cons of each?

In general consistent naming is the most important thing - whatever standard you adopt or create, it is only worth anything if it is used strictly.

After that basic things like good, unabbreviated, correctly-spelled meaningful names are key. I would avoid using hyphens, dashes, spaces, digits, underscores and special characters - they simply add to the name length without providing any benefits.

If possible you should express the type of data with the name. In your example, data key one, however you write it doesn't mean very much at all - making sure names are meaningful is as important as consistency.

Camel casing names is good practice, as long as it is consistently used - a simple rule such as "write only the first character in each term in capital letters" is good. It is readable and it shows the break in terms without the need for any other characters.

Terms that are initialisations or acronyms should use all capital letters - unless they are more that two letter long in which case they should use standard camel casing.

Whilst theses few rules are not part of any standard, they are solid and should work fine in the languages you mentioned.

Here are a few examples using the rules above with notes to show pros and cons...

bad-keys: should be avoided

• data_key_one (Ok I've got data key one...but what is data key one!?)
• HTTPAddress (the HTTPA sequence is hard to read, the terms are not clear)
• CustomerId (Id should not be camel cased like this)
• usersexchanged (is that "user sex changed" or "users exchanged"...?)
• AddressLine1 (using numbers can lead to confusion, also what is the 1st line - house name, street name?)

GoodKeys: using the above rules

• FinalScore (oh, that! data key one was a high score!)
• HttpAddress (much more readable, the terms are more clear)
• CustomerID (because we want an identifier, not a reference to the customers unconscious)
• UsersExchanged (phew!)
• AddressStreetName (much clearer, we didn't even need a number with a more meaningful name)