It's because avariable is different then aVariable. If you don't keep your capitalization consistent you may type the wrong variable names, leading to compiler errors, leading to more time wasted over something trivial. It's best to do either alllowercase or allCamalCase when variable naming to avoid stupid errors.
Name:
Anonymous2010-05-10 15:41
>>4
So it's just a consistence matter.
The point is that I don't like writing, say, "leftArm" since I don't get why "left" should be lowercase. Why not "LeftArm" instead?
WRITING VARIABLES ALL IN UPPER CASE IS BAD? WHY WOULD WRITING THE MOST COMMON ELEMENT IN COMPUTER PROGRAMS (ALONG WITH FUNCTIONS) WITH ANNOYING SCREAM-AT-YOU CASE BE BAD?
COME THINK ABOUT IT, WE SHOULD TYPE HASKELL ALL IN CAPS EXCEPT FOR DATA ELEMENTS, WHICH SHOULD BEGIN WITH A LOWER CASE LETTER LIKE SO:
>>5
It depends on the language conventions. CamelCase is great when it doesn't clash with anything else. In other cases (e.g. HASKAL), you're stuck with lowerCamelCase. In Lainsicp people look at you funny when you don't use minus-sign-separators. In C you can use Whatever_the_FUCK_you_want (except minus-sign-separators), but specific projects usually have specific conventions.
I prefer underscore_separators, because my screen is more than 4 inches wide, but a lot of people are still using 80 column terminals and have to suffer through crammed code to see everything.
I prefer underscore_separators, because my screen is more than 4 inches wide, but a lot of people are still using 80 column terminals and have to suffer through crammed code to see everything.
You bastard.
Name:
Anonymous2010-05-10 16:53
>>5
leftArm Is Used Over LeftArm Because To Type Like That In English Looks Plain Retarded =]
Name:
Anonymous2010-05-10 17:31
most languages have the convention of using all uppercase for constants
>>9
You're post is formatted like leftArm, and indeed looks retarded. LeftArm at least has some consistency.
Name:
Anonymous2010-05-10 18:01
>>11
No, no.
My post is formatted like int LeftArm, and indeed looks retarded. Traditionally (i.e. in C and every C-like after it), BactrianCase is used for enumerations, ALLCAPS and ALL_CAPS for macro definitions, and either dromedaryCase or underscores_as_spaces for general variables.
Imagine reading code as if you were reading prose. Capital letters for the beginning of each word are unnatural and ugly.
Clearly the winning method is underscores_as_spaces.
Name:
Anonymous2010-05-10 18:26
>>5
Because names starting with an upper case letter are usually used for types, with variables and functions starting with a lower case letter.
Name:
Anonymous2010-05-10 18:37
>>12
I don't know about anyone else, but I still find underscore_filled_variables to be jarring to look at; likely because of the rarity of underscores in everyday English. Using hyphenated variable names a la Lisp is my preferred solution, but this only works because Lisp is pretty permissive of what is allowed in symbols*. At least all reasonable people agree that camelCase is an abomination before the lord
* Special points go to (pre-R4RS ?) Scheme, which used to have the rule that was basically "if it isn't a number, it's a symbol"
Name:
Anonymous2010-05-10 19:31
I usuallyDo somethingLike thisBecause ohGod whatIs thisI dontEven
I wonder whether you could use the advanced operator overloading functionality in the newest standard of C++ to overload one space to be a part of the nearest token, while two spaces would act as a separator.
Wouldn't that be accomplished by just replacing all double spaces outside of string literals with a single space? -- Could be done easily with regular expressions.
Name:
Anonymous2010-05-11 1:01
it's a convention. Generally (at least in C and C++) uppercase names are used for defines (instructions for the compiler) not to be mistaken with normal variables:
example:
#define IFIFIF if
/*tells the compiler to substitute IFIFIF with "if" before compiling*/
IFIFIF (i==1) printf("hello world");
when you include some libraries sometimes they have defines and you don't want to create a variable that corresponds to a define.
example:
#include pooplibrary.h
int IFIFIF = 1;
if (IFIFIF) printf("hello world");
/*you think ififif is a variable, but in pooplibrary there's a "define IFIFIF if", so the compiler reads:
int if = 1;
if (if) printf("hello world");
which makes no sense and will give you an error
*/
Name:
Anonymous2010-05-11 1:47
>>5 The point is that I don't like writing, say, "leftArm" since I don't get why "left" should be lowercase. Why not "LeftArm" instead?
No reason, it's just a convention. Gosling went all about shitCase with Java and it kinda stuck. Haskell does the same thing.
You really don't need to use it though. If it makes you feel better, Google doesn't use shitCase at all; they use CamelCase for types and functions/methods, and underscore_names for variables and fields (reserving UPPER_CASE and kConstantCase for constants/macros). I actually don't use shitCase either; I use CamelCase for types only, and underscore_names for everything else, including most macros. If your macros are well-behaved (i.e. exactly one evaluation of each argument), there's no reason the caller should need to know whether it's a macro or a regular function.
Most library C code typically does everything with underscore_names and doesn't use uppercase characters at all except for preprocessor constants/macros. The C++ standard library is the same. And the Lisp family essentially never use uppercase characters, instead hyphen-casing everything (since the hyphen is not special in Lisp.)
Bottom line, pick a style you like and apply it consistently. That's all.
Most people agree that when creating pointers as variables, the clearest syntax is as follows (Warning: I'll be using shitCase, since that is my preferred capitalization style at the moment):
ClassName *objectName;
...but what about in a class method definition?
ExoticType *ClassName::methodName(int argOne, int *argTwo)
{
//...
or
ExoticType* ClassName::methodName(int argOne, int *argTwo)
{
//...