Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CamelCase vs underscores: Scientific showdown (2011)

whatheco.de

Post reply on HN
Print view View original

31–40 of 138 posts

Re: CamelCase vs underscores: Scientific showdown (2011)

#31

Post by jaynetics »

thrance wrote: post #16

With an azerty keyboard, underscores are a single stroke of the "8" key. This nullifies the "underscores are hard to type" argument. I'd even wager that the performance results are inverted in my country since snake_case does not require any press of the shift key, unlike camelCase. Also, I'm pretty sure I read a study one time that showed snake_case identifiers to be easier to read than camelCase ones. Anyways, I th…

This does make me wonder how much language preferences are really shaped by lofty philosophical arguments about different paradigms, and how much is in fact unconscious physical resistance: The awkwardness of typing the language on a given country's standard keyboard layout, individual hand physiology, individual visual perception, language verbosity (looking at you, Java)...

Re: CamelCase vs underscores: Scientific showdown (2011)

#32

Post by delichon »

rileymat2 wrote: post #22
delichon wrote: post #15

Earlier quoted context omitted.

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.

I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol) The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.

Removing keywords from variables is a big sacrifice when they are often such common glue words, like `and`, `or`, `if`, etc. Say `and` is the keyword and you want a variable called foo_and_bar. To get such words back you would need to add something so that the parser knows if

  foo and bar == true
means

  foo && bar == true
or

  foo_and_bar == true
?

You could fix it with ugliness like making the keyword `@and` or some such, or the variable `foo @and bar` but that's not an improvement.

Re: CamelCase vs underscores: Scientific showdown (2011)

#33

Post by Glacia »

j1elo wrote: post #20

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.

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.

Re: CamelCase vs underscores: Scientific showdown (2011)

#34

Post by pid-1 »

pekim wrote: post #29

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?

Re: CamelCase vs underscores: Scientific showdown (2011)

#35

Post by cletus »

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. This should be automatically removed so it doesn't generate extraneous changes on commit;

- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.

- Don't put the return type on a separate line. This is a really old school (K&R) C style

- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.

- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )

Re: CamelCase vs underscores: Scientific showdown (2011)

#36

Post by myfonj »

just•Give•Me•Extra•Kerning•Or•Ligatures

I still don't understand how comes that in times of programming fonts with fancy ligatures there is not a single one that would attempt to make camelCase more legible by slightly separating lowerUPPER sequences (presumably by constructing a "anti-ligature" for each unique pair that would have still width of two glyphs).

Or try to do anything similar to ease reading theseAnachronisticCharacterSequences.

Re: CamelCase vs underscores: Scientific showdown (2011)

#39

Post by ivan_gammel »

xmcqdpt2 wrote: post #24
navane wrote: post #12

Why can't we just have spaces in our variable names? These are both work arounds.

In languages without infix function calls, that should be possible, but I'm not sure how readable it would be. var initial factory = abstract configuration factory factory. configure new factory()

   var search result = users. find all by name (name);

   if (search result. is present()) { 
      return ok(search result. get());
   } else return not found();
It’s weird and syntax highlighting is absolutely necessary to read this.

Re: CamelCase vs underscores: Scientific showdown (2011)

#40

Post by ssl232 »

pekim wrote: post #29

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.

> The language's standard library will expose names using the language's convention

In Python the logging library is written in camel case (as it was heavily based on log4j) unlike most of the rest of the standard library, but the developers have let it be because fixing it would break backwards compatibility, and in any case PEP 8 [1] says consistency within a module is more important than global consistency.

In my opinion they should have fixed it in the move from Python 2 to 3, but I guess they had enough headaches from that.

[1] https://peps.python.org/pep-0008/

Post reply on HN