camelCase vs under_scores

January 21st, 2008

One of my pet peeves is code you can’t read or understand by quickly glancing over it. Since the roots of ActionScript come from a language where everything was written in camel case that doesn’t make it right. I have long favored underscoring my variable names and methods and here is why.

About 2 years ago when I worked on the new New York Jets site I had a great opportunity to talk to Matt Pelletier from East Media about Ruby naming conventions. We began talking about why Flash Developers used camel case and when he asked me why camel case was better I didn’t really have a valid answer. At the time my only excuse was to save file space (probably a couple of k here and there) and also because that is how the core methods in AS is written so I followed Macromedia (Now Adobe’s) convention. When I looked through his ruby code I realize just how much cleaner variable names were. I eventually began adopting the ruby style underscore with long descriptive variable/method names and haven’t looked back since.

Lets take a look at a few examples. It is hard to see the downfalls of camel case because as Flash and JavaScript developers you are trained to read it. Even the names “JavaScript ” and “ActionScript” are suppose to be written in Camel Case.

Example 1: Variable Name

var instName:String = “undefined”;

Now a more descriptive underscore variable name:

now the underscore version

var instance_name:String = “undefined”;

So whats the big deal? Well when you begin to move over to underscore naming conventions you will find it easier to write more descriptive variable names without having to truncate or abbreviate parts of the name because of how complex long camel case names look.

Example 2: Method Name

public function redrawMainDisplay ( data : Object ) : void { }

now the underscore version

public function redraw_main_display ( data : Object ) : void { }

It may just be me but I feel with the underscores you can easily read exactly what the method does without getting hung up in the alternating Case.

Example 3: Forced uppercase words

var containerMcGroup:MoiveClip = new MovieClip();

now the underscore name

var container_mc_group:MovieClip = new MovieClip();

So this one is kind of a special case example where you could just do “containerMCGroup” but that look really hard to read, so when you make the “C” Lowercase it adds a strange weight to the letters (sorry I am a designer after all so I pay attention to these kinds of things). With the underscore version you don’t have to force any part of the variable name to be upper or lower case just to make it fit the camel case naming convention.

The move towards using underscores is a difficult one and I don’t know may Flash Developers who do this but once you accept having longer variable/method names to have legible descriptive ones the benefits pay off.

15 Responses to “camelCase vs under_scores”

  1. sunny zandro Says:

    I have to agree with you on this. I have long been trying to have a standard with my codings, and have been battling whether to use underscore or CamelCasing. I also find it really hard to read my codes if it were CamelCased. The only problem now if i stick to underscore, is that, as you have mentioned, Actionscripts and other programming languages recommends camel casing. So when i use them, my codes looks weird, mixing both.

  2. FlashBum Says:

    Yeah, the mixed code is a pain to look at but I find that it helps me easily find my own code inside of core methods of AS. Unfortunately nothing is perfect but I hate to feed into a system that I find annoying. Thanks for the comment…

  3. PENIX Says:

    Agree 100%. Camel case doesn’t have any advantages over underscoring except consistency with others who use it.

  4. Peter Says:

    Nice! Thanks!

  5. felix Says:

    At the end of the day it doesn’t matter which you use. Your brain will interpret them both the same. Camel case is the AS standard right now, so you need a strong reason not to use it.

  6. kris Says:

    You make me want to try it out right now.

    However your container_mc_group example hurts one of the other conventions I’ve seen. Its when people put the var type in the instance name. containerGroupMc or more common mcContainerGroup like arrContainerGroups or stContainerGroupName. It would be very weird to put the ‘mc’ in the middle.

    Likely however, your example unintentionally reminded me of this worthless convention I personally don’t like it much at all - to put the var type in the name.

  7. kris Says:

    Actually I take that back a little - for objects in the FLA I do usually write out the type “btn” “mc” “select” etc, but never in the middle.

  8. Adam Hill Says:

    I work in Ruby on Rails, PHP, JS and AS. I use underscored for my variables, my functions and files where possible, and leave camelCase for classes… I do agree that it makes both easier to read and easier to recognise your own code.

    I have also found that some AS programmers also name all their websiteImagesAndFiles etc in camelCase, which degrades SEO if you want them to be indexed.

  9. Ben Overmyer Says:

    Though I’ve been using camelCase for as long as I can remember (BASICA anyone?), you’ve presented a compelling argument here. As a big fan of usability, I was impressed by the increase in readability you demonstrated with your instance_name example. I’ll have to try it out on my next project.

    @Adam - Agreed, underscore naming conventions improve SEO, and that makes underscoring worth the shift for developers who specialize in web production.

  10. Alex Loret de Mola Says:

    I think that each has their place, but I don’t know if the comparisons given are fair.

    For instance, you compare instName to instance_name. But if you compare equal things to each other “InstanceName” to “instance_name”, I think Camel Case is clearer… but again, it could just come down to personal preference.

    One thing I do like about Camel Case is the fact that you don’t have to constantly reach for the awkwardly placed underscore character. Either way you’re going to have to hit the shift key, so why not *just* shift instead of shift and the underscore character?

    Just my take on it.

  11. Ben Novakovic Says:

    I completely agree. I much prefer using underscored function names & variable names. Makes the code so much easier to read. Nice article.

  12. Todd Says:

    I think the readability is subjective. I’m looking at the examples and finding underscores less readable. But I’ve been using camelCase for years.

    Writability is not so subjective. Typing underscores, as another poster pointed out, is awkward. You could probably run a study showing that programmers who use camel case are less likely to develop carpal tunnel than those who use underscores. And when you use underscores in your naming conventions, short of editor assistance, you are doing a lot of reaching to the farthest regions of your keyboard.

  13. tom Says:

    Actually, I like camelCase is better for the one reason that it makes it easier to view each symbol as *one* symbol,”redraw_main_display” when scanned by the eye quickly can actually look like three separate symbols, “redraw - main - display” or “redraw main display”. The underscore just doesn’t stand out enough to link the words together as one symbol for me.

  14. Jozef Says:

    Good point from tom. I am using underscores a lot, but I have still troubles deciding which style to use for new projects. The camel case identifiers are much better ‘combinable’ in expressions, because they are visually more coherent than underscore-separated words; the dot is even less visible than underscore, so member references are harder to parse visually.

  15. The Flash Art of War » Blog Archive » iGiveInTo CamelCase Says:

    [...] conceded and am going back to camel case. I got lots of good feedback from my original post on CamelCase vs Underscore but the fact remains. The entire ActionScript language is written in CamelCase. Now that I am open [...]

Leave a Reply