Naming Conventions

There used to be many naming conventions back in the days, but lately it seems that two conventions are emerging as the two most popular among programmers. Underscore naming convention and camel case naming convention. Someone might argue that there are other popular conventions, but for now let’s compare these two and ask programmers out there which one they prefer. In the end a programmer might be bound to whatever is the standard for the language he is using, but this doesn’t prevent us from doing an out-of-context comparison.

Underscore naming convention uses all lower case words, and separate them with underscores. The common is to use this for variable and function names, and to use Pascal convention for classes, structures, enumerations, and interfaces. Underscores were used by C programmers, then C++ adopted the same convention for its keywords and Standard Templates Library, and later on Boost used the same convention, making this convention quite popular among C++ programmers, but not dominant as other programmers used various other conventions including Pascal and camel case conventions. Underscore convention is also used by PHP’s standard libraries and is pretty much the standard for PHP developers. Ruby also uses underscores, or so I heard.
On the other hand, camel case naming convention is mostly known to be the standard for Java and its little sister JavaScript, although you can find it in use in various other places. Camel case simply starts each word with an uppercase letter, except for the first word which remains in lower case. The words are not separated by any underscore, obviously. Like in the underscore convention, this applies mainly to variables and functions, while type names (classes, structures, interfaces, enumerations) remain in Pascal convention. C# uses a variation of this convention by limiting the camelcase to function parameters and local variables.
Of course each of the two conventions has its own strengths and weaknesses. The following list summarizes the strengths and weaknesses of the two:

• Underscores make phrases easier to read. Compare the underscore_naming_convention to the camelCaseNamingConvention.
• Camel case makes paragraphs easier to read! Of course, when you read code what’s important for you is to understand the overall operation or algorithm, not the words in a phrase. Compare the following:
  my_first_variable=my_second_variable-my_third_variable;
  to this:
  myFirstVariable=mySecondVariable-myThirdVariable;
  Obviously in this case the camel case is easier to read. From the first glance you realize it’s a subtraction between two variables, while in the case of underscores you need to concentrate before you realize where the minus sign is. You may even mistake it for being one long variable instead of two. This is a strong disadvantage for the underscore convention, however, coloring can solve this problem if the editor gives identifiers a different color from operators, but that’s dependent on the editor.
• Camel case is the negative of English. In english, the first word in a sentence starts with an upper case and the rest remains in lower case. This is probably true for many other human languages. Camel case is the exact opposite. This is mind itching indeed.
• Underscores are harder to type. Even with the availability of intellisense, you still need to type the underscore in many cases.
• Camel case is not consistent because with constants (which is all in upper case) you still need the underscores. On the other hand, the underscore convention CAN be consistent (if you decide to use underscores even for type names, which is doable, i.e. My_Type instead of MyType)