111–120 of 138 posts
Underscores are harder to type, at least on a US keyboard layout. To me, that's the single largest tag against underscore_separation.
On a US keyboard, _ is shift + -. To do CamelCase it's shift + c. Isn't that the same about of "difficulty"?
I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
Looking at you, C++ STL. Almost nobody names structs/classes all lowercase. This leads to silly style guidelines eg. in the Google c++ style guide:
- Name classes PascalCase (even if it's templated)
- Except if your class happens to be a templated container type, in which case name it all lowercase.
I got the solution! Given that spaces in identifiers cannot be used because we need to please the language tokenizers (shouldn't be the other way around with humans vs machines?), let's use TAB as a word separator! Configure TAB width = 1 character, and there you go.
Would allowing spaces in identifiers even introduce any ambiguity in most languages? I think the only languages I've seen where it would matter are functional languages. e.g. I think it'd be possible to write a Python program using spaces instead of underscores, and be able to unambiguously parse it with a slightly modified parser?
Since the space of valid syntax becomes so much larger, typos are more likely to result in valid but incorrect programs. Especially in dynamic interpreted languages like python.
I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
Postgres in particular has case-sensitivity quirks if you try to force the use of camelCase table names.
I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
What if you are creating a new language? Which one would you use?
Earlier quoted context omitted.
It's a joke. I made it up. Probably not a good idea to propagate it. ;) I think that there is an official name for lowercase-prefixed CamelCase, but I don't remember it.
That's camelCase. Uppercase would be PascalCase.
Underscore is a double-pinky keystroke. As someone who has battled RSI, I stopped using snake case and underscore-prefixed member variables because of the added stress all those underscores place on the weakest fingers.
I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
What if you are creating a new language? Which one would you use?
I'm firmly in the camp that doesn't care what the rule/style is, I just want an unambiguous rule. I'll just use whatever the language conventions are. Snake case in Java, for example, would be a hate crime. So would camel case in C. My general preferences beyond that are: - Opening braces on the same line (I see the article has examples where it's on a new line); - Two space indent, no tabs - No trailing white space.…
> Don't put the return type on a separate line. Generally yes, but stuff like ReturnType , T>>, U, HmmLetsAdd > can be on a line of its own.
ReturnType,
T,
>,
>,
U,
HmmLetsAdd,
>