Multi-Word Field Names

Databases
1

What is the best way to separate multi-word field names?

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! :wink:

6.) Other??

I used to prefer Pascal Case, but have grown to see the benefits of underscores - mainly that you never have to worry about remembering where/how you capitalize letters.

What does everyone else do and think?

TomTees

2

I think PascalCase and camelCase is easier to read compared to other conventions. I prefer PascalCase though.

3

I do OO so like ScallioXTX, I use camel case with Pascal case in reserve for classes and large scale objects like that. I don’t know why, but underscores really bug me. They are a key combo on my American English default key map. I don’t like trying to reach anything with my little pinky up there -, =, +. I hate having to backspace out all the errors when I hit the wrong key.

Though MySQL automatically converts my field names to all lower case. Is there a setting I can change to allow capital letters?

4

Yes, put lower_case_table_names=2 in your my.ini

5

Functions are lowerUpper
Classes are UpperUpper
Variables are lower with underscore

I find it easier to read past or long code when I know exactly what is being called by the naming style.

I also don’t shorten words but at the same time I don’t use bloated sentences. Instead of ‘fitlerByAssociatedCategoryId()’ I would write ‘filterByCategory()’ and make the function parse through either ids or slugs.

6

I do lowercase with underscores for both mysql tables and fields. I think this is just habit from using Symfony as my primary framework for so long.

I don’t think there is really any right or wrong method. As long as you stay consistent so you can read it and another programmer can learn and debug quickly.

7

camelCase :slight_smile:

http://www.megapixeljourneys.com/

8

I use a mix of underscores and camelBacks across all my code - that might sound odd, but there’s a method to my madness.

camelBacks I choose as my primary formatting method because it’s what javascript uses and suggests using, so I use it across all my code - HTML, CSS, PHP, PERL, etc - so I have one consistent naming convention. All my classes, ID’s and functions of the past… six years or so use camelBacks.

But I also use underscores in a handful of cases, often in COMBINATION with camelBacks. For example a section delimiter in a name - for example if I have two fieldsets with near identical information in the same form, the first one being “your info” and the second one being “spouses info” and both have a ‘name’ field, I’ll prefix the fieldset className before each.

your_name, spouses_name

I also often use underscores on classes or ID’s when using them as javascript hooks as it lets me divide up the element…

<span id=“sControl_myContent1”></span>
<div id=“myContent1”>Some text</div>

My javascript can then pulls all spans, checks for the sControl_ prefix (substr), attach the onclick handler, fill in some content, and use the end of the ID to target the DIV. Scripting off content is always shown and controls are not, scripting on the control gets added.

Another example would be a code library. If I have multiple library files I’ll use the prefix_ structure to say what library a function is from, while using camelBacks for the actual function name.

For example:


function common_camelBack($inString) {
	return lcfirst(str_replace(
		array(
			' ',"\
","\	","\\r",'&nbsp;'
		),'',ucwords($inString)
	));
}

function common_randomPassword($min=8,$max=12) {

I then know those functions are stored in /libraries/common.php, just as I would know:


function forms_isValidEmail($address) {

is in /libraries/forms.php

Also prevents namespace headaches.

Really though it just helps me make my code feel cleaner/clearer. Same reason I use XHTML and have burned out tab and enter keys on “Model M” Keyboards. (which if you know what those are, your head just exploded like you were in the same room with Micheal Ironsides)

9

Then why did you use SitePoint and Sitepoint as examples when you have just said it is one word?

…and it can only be SitepointNumber using the camelcase approach.

There are no compound words that use mid-word capitalisations. Anyone who uses them like this is using them incorrectly. That’s the whole point of it being a new compound word, and not separate words!

Neither approach is any more or less ambiguous than the other.

10

I try to use a single word to describe columns. I like to prevent ambiguous column names by using a second word sometimes though. I use underscores when I do this.

Rather than the names “id”, or “order”, I might use “category_id”, “image_id”, and “insert_order”.

11

naming fields is actually your preference.
for me, camel case is good

12

I’ve used all of the above and then some (I’ve even tried dashes before).
My first tables were very simple newbie experiments and single word names worked fine.

But when I eventualy needed to differentiate I tried adding numbers eg.
item1
item2
item3
Ugh! Don’t do that! It may be OK while the code is fresh in the memory but try figuring out what is what after you’ve been away for a while.

Then for a while I used alternately PascalCase camelCase under_score and allthewordsputtogether.
Ugh again! Don’t do that either. Find a way and stick with it.

I now use lowercase underscore, saves a lot on the mental gymnastics.

13

I am an American and I had to Google :blush:
Zoning Improvement Plan

I won’t say I’d prefer zoning_improvement_plan_code !

14

One thing to have in mind is that if you migrate from Windows to any “Linux”/Unix system (except Mac’s unix versions, and maybe some other), or between some Unix versions the databse and table names and their corresponding directories are case sensitive (Win and Mac aren’t). And what about moving to other db’s? It may not be of any importance today, but could be a consideration for the future!

If so, a lower case uniformity is probably the best - That is perhaps also important when you write SELECTs or when you program functions, procedures, and triggers? - But my experience with MySQL under “ux”-systems is limitied to basic php-programming without any db’s involved.

15

I use underscores as well for everything (and I need the [Shift]+[-] combination as well). It just looks prettier to me, and I don’t have to worry about whether a letter is a lower-case L or an upper-case I if using a different computer.

16

I use lowerUpper for functions and variables (although controversially, I put the type before the name as well, so I actually use $typeUpperUpper for vars)

UpperUpper for classes as well. I tend to use underscores in mysql field names for some reason.

17

It’s a key combo on a UK English keyboard too … Shift and - (between 0 and = keys) give the _ character. :wink:

18

How do you mean? Surely it’s a direct translation from one to the other - if you have to remember where/how you capitalise letters, you also have to remember where/how you place underscores!

19

Does using underscores (e.g. “sale_unit_price”) affect performance?

Can that blow up MySQL (or another non-MS Access database)?

TomTees

20

As long as you’re consistent, it doesn’t matter a whole lot.

The only place where I’ve seen problems crop up is when you have double letters together–the same letter at the end of a word and the same letter at the start of the next one

Something like: “saveeverytime”.

It can lead to typos and such.