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?

10 Answers 10


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.

  • 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? Commented Aug 22, 2012 at 18:53

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!

  • 3
    Agreed. With his first listed convention, how does one know whether ihaveagirlfriendwhoishot should be "[...]who is hot" or "[...]who I shot"?
    – Craige
    Commented Feb 22, 2011 at 15:51

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.

  • someone should upvote this more because i feel the same
    – ColacX
    Commented Aug 3, 2014 at 10:54
  • MyYaqrtTeam is the correct one
    – Gqqnbig
    Commented Mar 24, 2018 at 7:10

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.

  • 1
    so does 'shift + char' for uppercase letters...
    – 0TTT0
    Commented Mar 18, 2018 at 1:25
  • 1
    @0TTT0 true, but the underscore is an extra_inconvenient_character comparedToCamelCase. But despite that I'm still in favour of snake case for better readability.
    – mojuba
    Commented Mar 18, 2018 at 9:30

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


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.


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#.


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.


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.


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

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