camelCase vs under_scores

Posted by Jesse Freeman | Filed under Advanced Topics

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.

Permalink | January 21st, 2008

  • Nathan
    In most applications, you'll also need a database side. I typically use an underscore when naming join tables. For example: "user_email". The problem is that for all of the other tables, I think that it's best to use camel casing. Otherwise, your join tables will have multiple underscores, which will name it hard to know where one tablename ends and the next one starts. "user_phone_number" is a lot harder to read that "user_phoneNumber".

    What does this have to do with other programming languages? The issue is that no matter what programming language you use, you will most likely also have a database backend. For smaller projects, the person who works on the database will also be the one working on the rest of the application. And to simplify things, it's best to just use the same standard for both, rather than mixing it up.
  • Maudlin
    great post, thanks for providing so much. Keep up the good posts!
  • There is a very good and valid argument for both camelCase and underscored, depending on the language.

    When skimming through PHP code I can much more easily identify camel-cased variables and functions as my own (vs. core functions which use underscores). When I see underscores I automatically identify the item as a built-in core function (PHP). This is whym, in PHP, I prefer writing my own function and vars in camelCase and my classes in MixedCase.

    That said, if I were writing for a language that had core functions with camel cased core functions I would probably do the opposite.

    The point is to 'encapsulate' my code in a way that is readable and identifiable compared to the core functions.
  • John
    '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.'

    What benefit does it have to see it as one symbol? If an identifier is named "redraw_main_display", it is trying to communicate three separate words in the English language. Programming is about communication. Rather than parsing code like a compiler, you should focus on what it's trying to say and write code as clearly as possible in the human language (ex: English).

    random_shuffle(cards);

    ... should be read as three words indicating that we're randomly shuffling cards. To read it as two tokens seems awfully robotic. I see little benefit to doing unless you are a compiler.
  • John
    "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."

    Actually, the reverse might be just as likely true. Carpal tunnel develops more frequently from frequent mouse users than people who type a lot. Studies suggest that this is likely due to constantly keeping the wrists locked in place.

    Anyway, I like both camel case and underscore. The only complaint I have with camel case is that people tend to abuse it more. I've actually seen quite often cases where people were tempted to put underscores into a camelCase_Identifer <-- like this to emphasize the separation, and that's just plain ridiculous.
  • John
    The readability of underscore is not subjective, particularly with lengthy names. IfITypeThisSentenceInCamelCase, it_would_take_longer_for_you_to_read_it.

    That said, consistency should be the goal above all. If your language uses a certain naming convention, it often helps to follow it. Some might make an excuse and try to state that the distinction is useful. It's not if you are following modern software engineering standards in almost any language which now emphasize interfaces and polymorphism more than focusing on individual types. Distinguishing your own types and interfaces from others just makes your code less consistent.
  • Daniel Ribeiro Maciel
    The readability of underscores is not subjective indeed, but camel case makes much easier to identify previously seen symbols on a code.

    In short, undercores are easier to read, but are harder to identify in a crowd.

    Why?
    Because capital letters mixed in the text makes it look more like a shape and less like text.
    Shapes are easier for our brains to identify amongst other shapes (or text).
    In underscores you must read the full sentence in order to properly identify it.

    Source code is not a regular text. Expressions are repeated all over it. You don't usually see a variable or method that is used only once. In that case it is extremely useful to be able to quickly identify replicas since we repeat them so much.
  • I am sure it is only relevant to people who program. One thing I talk about to a lot of developers is how repetitive and personal programing is. When you do something long enough, such a use CamelCase, you find it hard to change. Programing is habit forming. I have been using CamelCase for a while now and the only benefit I can see is that my functions and class formatting matches the rest of the language as a whole. Still not happy about it and I use underscores in my PHP code. The big issue for me now has to do with the framework code I am writing and making sure it follows the language standard regardless if I like it or not.
  • Rafael Cosman
    Has anyone thought of designing an experiment in which subjects were asked to read something in CamelCase or under_score? You could compare reading speed and the percent of people that understood what they read in that time, and could conclusively determine which is better.
  • I have bookmarked this informativ site. Thanks Kfz Versicherung
  • Jozef
    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.
  • tom
    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.
  • Todd
    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.
  • I completely agree. I much prefer using underscored function names & variable names. Makes the code so much easier to read. Nice article.
  • 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.
  • 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.
  • 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.
  • kris
    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.
  • kris
    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.
  • 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.
  • Nice! Thanks!
  • Agree 100%. Camel case doesn't have any advantages over underscoring except consistency with others who use it.
  • 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...
  • sunny zandro
    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.
blog comments powered by Disqus

Categories

Inspiration

The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.

by Sun Tzu, the Art of War