Currently, there are many standards for variable names, but two of them are the most popular among programmers: these are camel case ("Camel" notation) and underscore (naming variables using the underscore character as a separator). Some may argue that there are other popular standards, but in this article we will compare these two and learn from the programmers what standard they adhere to. Of course, some programmers are bound by the coding standards of the language or framework they use, but we will try to make an independent comparison.
Standard naming using underscores is that all words are written in lower case letters and separated by an underscore (_) character. Usually, this standard is used in the names of functions and variables, and for the names of classes, structures, and interfaces, the Pascal standard is used. For some reason, the article says nothing about it, but as I found in Pascal style in Wikipedia, this is UpperCamelCase, when the first the word begins with a capital letter,
proof ). Underscore was originally used by C programmers, and then was used by C ++ developers in the naming of keywords and in the STL library, and then in Boost, due to which this standard became very popular among C ++ programmers, but did not become dominant. Also, this standard is used in the names of standard PHP functions, and is very popular among PHP programmers. They say that Ruby also uses underscores.
On the other hand, camel notation is a standard in the Java language and its younger sister JavaScript, although it can also be found in other places. According to this standard, all words in the name begin with a capital letter, except the first. In this case, of course, no separators like underscores are used. Usually, this standard is applied to the names of functions and variables, while the names of classes (structures, interfaces) use the Pascal standard. In C #, camelCase is used in part: its scope is limited to function parameter names and local variables.
')
Each of these two standards has its strengths and weaknesses. Let's list the main ones:
- The underscore is better readable: compare the standard_with the underscore and the standardNapisCapital Letters
- But camel case makes it easier to read lines , for example:
my_first_var = my_second_var-my_third_var
and
myFirstVar = mySecondVar-myThirdVar
Obviously, the camel case reads better: in the case of the underscore and the minus operator, the expression at first glance can be taken as one variable, but syntax highlighting can solve this problem. - Camel Case is the opposite of English, Russian and many other languages: in ordinary languages, sentences begin with a capital letter, and all other words are written in lowercase, in the case of camel case, everything happens the other way around. This is a real brain explosion.
- Underline is harder to type. Even with intellisense, in many cases it is necessary to type the underscore character.
- Camel Case is inconsistent, because when using constants (which are written entirely in capital letters) we have to use underscores. On the other hand, the naming standard using underscores can be complete if you decide to use underscores as separators in class names (structures, interfaces)
From the translator: I tried to translate the article as close as possible to the original.
I'd like to add that in my projects I prefer to use Camel Case, I only use the abbreviated type of variable as the first word (bProductActive, iProductsCount, sUserName), thus solving the problem of “brain explosion” - all words of the sentence begin with a capital letter.
In addition, there were a lot of controversy with colleagues on the subject of abbreviations when using camel notation: how to write GenerateHTMLFromText or GenerateHtmlFromText more correctly, finally settled on the second variant, but the feeling of unsolved problem still gnaws a little.
Well, about the fact that JavaScript is the younger sister of Java, the author caught up a bit, after all, these are completely different languages, they all have in common only the name and standards of code design.