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.
CamelCase vs underscores: Scientific showdown (2011)
41–50 of 138 posts
Re: CamelCase vs underscores: Scientific showdown (2011)
#42Re: CamelCase vs underscores: Scientific showdown (2011)
#43I 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.
i'm pretty sure ALGOL allowed spaces in identifiers. Probably some other old programming languages too. For the most part, it's just a tradition at this point.
This, and the fact that variable names are allowed to be implicitly defined, lead to the famous bug:
DO 10 I = 1.100
declared the variable `DO10I` with a value of 1.1, instead of the loop from 1 to 100 and declaring the "statement label" 10: DO 10 I = 1,100
SUM = SUM + I
10 CONTINUERe: CamelCase vs underscores: Scientific showdown (2011)
#44Any kebab-case fans here?
Re: CamelCase vs underscores: Scientific showdown (2011)
#45hyphen-case is worth the grammar concessions (like making whitespace between binary operators mandatory).
Also allowing hyphens generally leads to issues when interoperating with other languages that don't support hyphens. Probably the best example of this is CSS which does allow hyphens, and Javascript which doesn't. `background-color` in CSS gets translated to `backgroundColor` in JS.
It's an annoying paper cut that trips up beginners and makes code less greppable. I generally avoid hyphens wherever possible for that reason.
Re: CamelCase vs underscores: Scientific showdown (2011)
#46I 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.
i'm pretty sure ALGOL allowed spaces in identifiers. Probably some other old programming languages too. For the most part, it's just a tradition at this point.
> It is good to have names containing multiple words, but there is little agreement on how to do that since spaces are not allowed inside of names. There is wun [sic] school that insists on the use of camel case, where the first letter of words are capitalized to indicate the word boundaries. There is another school that insists that _ underbar should be used in place of space to show the word boundaries. There is a third school that just runs all the words together, losing the word boundaries. The schools are unable to agree on the best practice. This argument has been going on for years and years and does not appear to be approaching any kind of consensus. That is because all of the schools are wrong.
> The correct answer is to use spaces to separate the words. Programming languages currently do not allow this because compilers in the 1950s had to run in a very small number of kilowords, and spaces in names were considered an unaffordable luxury. FORTRAN actually pulled it off, allowing names to contain spaces, but later languages did not follow that good example ... I am hoping that the next language does the right thing and allows names to contain spaces to improve readability.
Re: CamelCase vs underscores: Scientific showdown (2011)
#47Why can't we just have spaces in our variable names? These are both work arounds.
Re: CamelCase vs underscores: Scientific showdown (2011)
#48I'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.…
While you could apply the same kind of automated logic to naming, the risk of collision is non zero and moreover would likely break runtime mechanisms like reflection, etc.
Re: CamelCase vs underscores: Scientific showdown (2011)
#49Earlier quoted context omitted.
IAgreeThatSnakeCaseIsEasierToRead,ThoughIfWeWereToUseCamelCaseMoreWeWouldBeSavingAGoodAmountOfSpace,WhichMightBeUsefulForNarrowBlocksOfText.I'mSuprisedItHasn'tCaughtOnInProse.Actually,LookingAtThis,MaybeIt'sAGoodThingItHasn'tCaughtOnForProse.
Classical Latin used all caps no spaces, so rather than caught on we moved away from it. https://en.wikipedia.org/wiki/Scriptio_continua
Re: CamelCase vs underscores: Scientific showdown (2011)
#50Why can't we just have spaces in our variable names? These are both work arounds.
So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and end, like quotes or a special declaration, which would be harder for the brain to parse. If you know a better way please share it.
That's not a problem at all, as long a a newline isn't treated as space and you don't use ML style function application, where a space is used to separate the argument(s) from the function name - `f x` instead of `f(x)`.