Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Variable names can be written in many ways, but the most common that I'm familiar with are:

  • thisisavariable,
  • this_is_a_variable, and
  • thisIsAVariable.

Which of these are preferred, and why?

share|improve this question
add comment

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, MichaelT, Robert Harvey, Dynamic Dec 8 '13 at 23:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

10 Answers

up vote 29 down vote accepted

Some programming languages or frameworks have their conventions about variable naming.

I believe that more important than the way you name variables is to be consistent and stick with certain style during a project. This becomes extremely important within a team, where the code must be easily understood at first sight by anyone who reads it.

IMHO the rest is a matter of taste.

share|improve this answer
    
Hi, sorry to barge in so late. The answer is good on its own, but I often run into the following dilemma about conventions. Let's say a project is using several components devised in multiple frameworks/languages. Some of these frameworks by convention use camel case and some use underscores. Should we prioritize being consistent throughput the project or sticking to the specific frameworks' conventions? –  Greg Kramida Aug 22 '12 at 18:53
add comment

Personal I prefer camel case. The most important is that you can read the variable name and it's meaning. And because of that I think it does not matter if you use undercases or camel case. Only your first example (thisisavariable) is a bad way I think beacause it is heavy hard to read!

Generally it depends on your programming language!

share|improve this answer
2  
Agreed. With his first listed convention, how does one know whether ihaveagirlfriendwhoishot should be "[...]who is hot" or "[...]who I shot"? –  Craige Feb 22 '11 at 15:51
add comment

Bjarne Stroustrup claims the underscore naming is the most readable according to some research. I' not sure which research he is referring to, but obviously, words separated with blanks are most naturally readable compared to other styles.

As for typing, unfortunately the underscore style loses the case a bit: _ is not the most convenient symbol for typing, requires both hands to be involved.

share|improve this answer
add comment

Sometimes I prefer underscore when you have to deal with acronymns in variable names.

For instance, suppose "My YAQRT team" is a meaningful variable name.


1.) MyYAQRTTeam -or-
2.) MyYaqrtTeam -or-
3.) my_yaqrt_team
Which is best? I prefer number 3. Although I like camel case, when you have acronymns, it just makes things difficult to read.

share|improve this answer
add comment

It depends on the programming language. Underscores are the preferred naming convention in Python. Camel case is the preferred convention in C#.

share|improve this answer
add comment

I'd say the first kindofvariablenames should never be used.

Anything else can be used depending on the environment. Not only your own choice matters here, but also the language and the libraries styles. Languages may have explicit style guides. Libraries may have ad-hoc naming, but you'd better take it into account as well.

For example, if you write under Windows in a language with strict typing, where API functions are NamedLikeThat and soDoTheirArguments, it seems logical to follow the trend and use camel case with type prefixes. In the same way, if you write under Unix in a language with weak typing, a typical_call(may_look, like_that) and it's also fine.

There is no universal truth here, everything goes as soon as it's readable and everyone agrees. You can extend the rules in any way you like. I for example have this aged habit of naming local parameters starting with underscore, so that for example a C++ constructor may look like this:

C::C(const int _iCount) : m_iCount(_iCount) { }

and find it very convenient.

share|improve this answer
add comment

The specifics don't really matter as long as everybody agrees.

I would choose one that allready exists:

  • to help the adopting to new people on the team
  • there is no need to invent the wheel yourself
  • you might get tooling support to check and refactor

Most coding standards are for a specific language and make a distinction between the type of variables. (private, public, static etc.) so you can tell what kind of variable it is by just looking at the name.

For c# examples look at this blog post for different coding guidelines for c#.

share|improve this answer
add comment

The preferred one is the one of the language and libraries you are using. It's important to have a consistent style, and adhering to the used environment prevents mixing different styles. Though not every language has such a dominant style (C++ comes to mind). In these cases it's purely personal preference. Just agree on something and stick to it.

share|improve this answer
add comment

This totally depends upon mutual agreement by team members. After all, code is meant for developers, reviewers, auditors and other team members, and hence needs to be clean, easily modifiable and ambiguity free. Variables have little scope for any particular class or function and are expected to have some meaningful name. As long as variable conveys its intension, case remains nominal. And hence any approved standard can be used and followed during development.

share|improve this answer
add comment

All of them are preferred. It just depends on who you ask.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.