Field names with multiple words

Tom_Tees

What is the best way to tackle field names that are multiple words (e.g. "First Name")?

Here are some ways that I have come across online...

1.) Pascal case (e.g. "FirstName")

2.) Camel Case (e.g. "firstName")

3.) Underscores (e.g. "first_name")

4.) No Separation (e.g. "firstname")

5.) Spaces (e.g. "first name") I already know the answer on this one! 😉

6.) Other??

What approach does everyone here use?

TomTees

bradgrafelman

By "field" names, I'm assuming you mean column names in a SQL database?

If so, it's pretty much up to you. Be consistent with the rest of your project if at all possible, and/or follow any previously established coding practices/guidelines if applicable.

While it's certainly possible to use spaces in a column name, it's generally discouraged/frowned upon.

dagon

Tom Tees;10953533 wrote:
What approach does everyone here use?

2 and when i forget 3, but its up to you.

mrbaseball34

Coming from Access, I know the temptation you must feel to use spaces in your column names.
;-)

However, you have to begin to think differently when working with mySQL. I would venture to say that the majority of PHP/mySQL developers use #3 due to the fact that PHP is a case sensitive language and the majority of code is written in lowercase.

My mySQL development utility, HeidiSQL, allows me to create columns with any case as well as spaces in the names, but I do use #3 as a rule.

bradgrafelman

mrbaseball34 wrote:
PHP is a case sensitive language

Not entirely true... function/class/method/etc. names aren't case sensitive. But yes, variables and array indexes are.

In one project I'm working on, camelCase is used for just about everything (except constants) - including variables, methods, and DB columns. In a different project (entirely different codebase), however, they use mixed case and underscores. It's not that one is necessarily superior over the other... all I have to do is follow the guidelines laid out before me.

If I were beginning a new project, however, my personal preference would probably be #2. I'm almost disappointed, though, that Hungarian notation wasn't mentioned as an option! :p

mrbaseball34

bradgrafelman;10954381 wrote:
<SNIP>
If I were beginning a new project, however, my personal preference would probably be #2. I'm almost disappointed, though, that Hungarian notation wasn't mentioned as an option! :p

Well Hungarian is actually the same as #2, you just prefix the variable name with an abbreviation for the type in lowercase letters, i.e. $intUser_ID, or $strFirstName

Weedpacket

That's a bit of a misunderstanding about Hungarian notation; it's not so much the syntactic type of the field that is supposed to be prefixed, but the semantic one. The syntactic type is already there in the declaration; a count and a ranking are both integers, but they'd have different prefixes, because the categories of functions that apply are different (it makes sense to add counts, but not rankings).

http://msdn.microsoft.com/en-us/library/aa260976%28VS.60%29.aspx

mrbaseball34

Yes, I understand the difference between Systems vs. Apps Hungarian.

WikiPedia wrote:
In Systems Hungarian notation, the prefix encodes the actual data type of the variable.

Apps Hungarian notation does not encode the actual data type, but rather, it gives a hint as to what the variable's purpose is, or what it represents.

Weedpacket

Yes, and do you know the difference in their use, and which would be applicable here?

zypher11

From what ive seen (and in my own preference) #2 is probably the most widely used since it it considered "good practice" to write variable names like that in either VB, C#, or PHP. It just keeps you from making any mistakes really. If you get used to writing like #2 then you make a col name First_Name you might write your query without thinking about it and use firstName and then wonder what the hell is going wrong before you finally catch it

Res

Consistency is the biggest there. What ever method do it all the way through.

Personally I prefer #2 for field names in the DB and variables #3 for function/method/instantiated objects and #1 for classes. I'm weird though and my OCD requires these things look visually distinct to the scope.

I disdain #4.

cretaceous

I use 3 but have been doing more jquery stuff so that's all 2
and class stuff is 1 or 2 ..

I find underscores easy to read and camel case hard to read and even ugly to look at
(yes it's awkward that aesthetics should rear their head here)

I tend to abbreviate quite a lot so first name becomes f_name
though I noticed recently my names are getting longer - more description means less thinking

bradgrafelman

Anyone else use Google Protocol Buffers in their projects? If so, they've got their own recommended style (a mix of 1, 4, and all uppercase, depending upon what you're naming).

EDIT: Forgot to mention... I'm not sure if this applies towards PHP... I'm strictly a Java/SQL programmer at work now. :p