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?
|
Variable names can be written in many ways, but the most common that I'm familiar with are:
Which of these are preferred, and why? |
||||
|
|
|
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. |
|||||||
|
|
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 ( Generally it depends on your programming language! |
|||||
|
|
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. |
|||
|
|
I would choose one that allready exists:
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#. |
|||
|
|
|
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. |
|||
|
|
|
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. |
|||
|
|
|
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.
Which is best? I prefer number 3. Although I like camel case, when you have acronymns, it just makes things difficult to read.
|
|||
|
|