6 ms·

An underscore is a word-separating space that selects as part of the sentence. If you use spaces in your normal writing, there's no reason you shouldn't use sp

An underscore is a word-separating space that selects as part of the sentence. If you use spaces in your normal writing, there's no reason you shouldn't use spaces in programming - except that a space prevents you from easily selecting the whole phrase, a very common operation programmers face. So they replaced the space with a character that is effectively identical, but works better. Some people figured they could just remove it. WellTellMeThis,DoesItMakeMyTextMoreReadableToYou? If you argue that camelcase is better, then shouldn't we adopt it into normal writing too? Why not?

paulcole 4y ago
CamelCase doesn’t need to be more readable, it just needs to be readable enough. And when you keep names short, it is.
- nmz 4y ago
  3 wordsIsTheLimit, afterThat, its_better_to_use_underscores.
__ryan__ 4y ago
There’s plenty of things that are done in code that we don’t adopt in prose and vice versa. You could just as easily make the case for adopting underscores in place of spaces in prose to increase readability, but we haven’t done that. In code, you have to balance readability in many contexts. Snake case and kebab case look more readable in isolation, but do they look better when used as part of a larger expression, for example part of a chain of member access and method calls and argument passing? I don’t think the answer is obvious, and it probably depends on other formatting affordances (e.g. breaking the expression up on multiple lines). I’m on mobile and I don’t trust HN’s formatting to do any justice with examples, but it might be worth trying it out in your code editor.
- TomSwirly 4y ago
  It'sSimplyNotVeryNaturalToReadTextWhereCapitalLettersTakeThePlaceOfSpaces,AndThereIsThe"NASAIs"ProblemToo. In_most_fonts,_the_underscore_character_is_visually_like_a_space,_and_you_can_distinguish_"NASA_is"_and_Mike_vs_mike.
  - Clamchop 4y ago
    Is it not natural or are you just unpracticed at it?
  - __ryan__ 4y ago
    I’m specifically saying that prose/text and code are different contexts that don’t necessarily benefit from the same styles of writing. What I was saying is that just because spaces in prose naturally improves visibility does not _necessarily_ mean that underscores and dashes improve overall readability across many contexts _in real code_, because code and prose are different. It could be the case, but it’s not the obvious innate property people are suggesting it is. If it such an obvious innate improvement in readability, then why don’t we replace spaces with underscores in prose and handwriting? It would remove any ambiguity between intentional separation and awkward unintentional spacing or kerning. But we don’t and haven’t done that for some reason, so there must be something else at play. Your examples (and many examples in this thread) of long sentences in these formats are not what code actually look like. Real code has meaningful symbols and syntax that occur between identifiers that carry semantic meaning. Maybe the lack of symbols in identifiers in camel and pascal case make it easier to identify these other symbols and syntactic elements, so you end up with better overall readability. Maybe adding to that the flexibility of using camel and pascal and upper snake case for different "types" of identifiers improves mental mapping of code concepts that you'd lose if you always used snake case. Again, I'm only making the argument that readability in code and readability in prose are two totally different things, and the effects of different casing and different identifier naming schemes are likely more subtle than what is better clearly separating words in the identifier.
jfk13 4y ago
I don't think the issue with spaces is primarily about selection; it's about parsing.
- hypertele-Xii 4y ago
  When I write code I'm not thinking about parsing. When I write code, I'm thinking about writing code. Underscores makes coding easier (for improved selection behavior). Ergo, the issue with spaces is primarily about selection (for me).
tgv 4y ago
> So they replaced the space with a character that is effectively identical I don't think that's the reason. The reason was ease of parsing. It's harder to write a token recognizer if spaces are allowed in identifiers and distinguish them from type names and reserved words. ALGOL-68 famously did allow spaces in identifiers, e.g. https://rosettacode.org/wiki/Boustrophedon_transform#ALGOL_68 https://rosettacode.org/wiki/Boustrophedon_transform#ALGOL_6...
dgb23 4y ago
I like the notion of discriminating the general kind that names refer to with different separation styles. I think the most common are: - camelCase - PascalCase - snake_case - kebab-case - |sentence case| I think the last one can be used in CL, but not 100% sure. Some examples: - Clojure prefers kebab-case mostly, but some types and definitions use PascalCase to imply that there is a more direct mapping to a Java class. Clojure prefers to use namespaces to name things that belong together over long, prefixed names. Single letter names are common for function parameters such as 'm' for maps, 's' for strings and so on. - Go prefers camelCase for private/local types fields and functions. When PascalCase is used, then the name is exported. Go generally prefers short, often abbreviated names (Unix/C heritage). - Rust prefers PascalCase for type definitions, snake_case for function names, locals and parameter names. - Both in Go and Rust, packagas/modules/crates give additional naming structure but also control visibility. So those things have multiple jobs. So generally the-wayWe_Type/And-NameThings in different languages can give us a bit more structure and meaning without cluttering the syntax with additional keywords. A big side-benefit is that we then don't need to decide which style to use! It's better to have a uniform style than your personally preferred one IMO.
- kagevf 4y ago
  > I think the last one can be used in CL, but not 100% sure. You can create a symbol that way: (let ((|my symbol| 123)) |my symbol|) => 123
- toastal 4y ago
  If you think that last bit of wacky casing combinations is offensive, wait BEM-style CSS selectors—not the philosophy or separation of components, just the selectors themselves. Basically any other naming or separator selection would have been better.
- atombender 4y ago
  I never understood why some languages like Rust are so inconsistent here: snake_case for non-type identifiers, but PascalCase rather than Snake_Pascal_Case for types. Maybe OP's study is real, but the underscore has always bothered me. I'm fine with it in principle, but it creates visual noise, since pretty much all fonts put the underscore below the baseline. Here's a mockup that fixes the vertical placement of the underscore (right hand side): https://i.imgur.com/5sF3QMH.png https://i.imgur.com/5sF3QMH.png Much better!
ulizzle 4y ago
Because "normal" writing (prose) isn't code. The medium dictates the delivery.
- hypertele-Xii 4y ago
  Normal writing and code are both text to be read by humans. They are the same medium with regards to readability. Our brains use the same circuits we developed to read normal writing to read code. I haven't seen any evidence to the contrary.

paulcole 4y ago

CamelCase doesn’t need to be more readable, it just needs to be readable enough. And when you keep names short, it is.

nmz 4y ago
3 wordsIsTheLimit, afterThat, its_better_to_use_underscores.

__ryan__ 4y ago

There’s plenty of things that are done in code that we don’t adopt in prose and vice versa. You could just as easily make the case for adopting underscores in place of spaces in prose to increase readability, but we haven’t done that. In code, you have to balance readability in many contexts. Snake case and kebab case look more readable in isolation, but do they look better when used as part of a larger expression, for example part of a chain of member access and method calls and argument passing? I don’t think the answer is obvious, and it probably depends on other formatting affordances (e.g. breaking the expression up on multiple lines). I’m on mobile and I don’t trust HN’s formatting to do any justice with examples, but it might be worth trying it out in your code editor.

TomSwirly 4y ago
It'sSimplyNotVeryNaturalToReadTextWhereCapitalLettersTakeThePlaceOfSpaces,AndThereIsThe"NASAIs"ProblemToo. In_most_fonts,_the_underscore_character_is_visually_like_a_space,_and_you_can_distinguish_"NASA_is"_and_Mike_vs_mike.
- Clamchop 4y ago
  Is it not natural or are you just unpracticed at it?
- __ryan__ 4y ago
  I’m specifically saying that prose/text and code are different contexts that don’t necessarily benefit from the same styles of writing. What I was saying is that just because spaces in prose naturally improves visibility does not _necessarily_ mean that underscores and dashes improve overall readability across many contexts _in real code_, because code and prose are different. It could be the case, but it’s not the obvious innate property people are suggesting it is. If it such an obvious innate improvement in readability, then why don’t we replace spaces with underscores in prose and handwriting? It would remove any ambiguity between intentional separation and awkward unintentional spacing or kerning. But we don’t and haven’t done that for some reason, so there must be something else at play. Your examples (and many examples in this thread) of long sentences in these formats are not what code actually look like. Real code has meaningful symbols and syntax that occur between identifiers that carry semantic meaning. Maybe the lack of symbols in identifiers in camel and pascal case make it easier to identify these other symbols and syntactic elements, so you end up with better overall readability. Maybe adding to that the flexibility of using camel and pascal and upper snake case for different "types" of identifiers improves mental mapping of code concepts that you'd lose if you always used snake case. Again, I'm only making the argument that readability in code and readability in prose are two totally different things, and the effects of different casing and different identifier naming schemes are likely more subtle than what is better clearly separating words in the identifier.

jfk13 4y ago

I don't think the issue with spaces is primarily about selection; it's about parsing.

hypertele-Xii 4y ago
When I write code I'm not thinking about parsing. When I write code, I'm thinking about writing code. Underscores makes coding easier (for improved selection behavior). Ergo, the issue with spaces is primarily about selection (for me).

tgv 4y ago

> So they replaced the space with a character that is effectively identical I don't think that's the reason. The reason was ease of parsing. It's harder to write a token recognizer if spaces are allowed in identifiers and distinguish them from type names and reserved words. ALGOL-68 famously did allow spaces in identifiers, e.g. https://rosettacode.org/wiki/Boustrophedon_transform#ALGOL_68 https://rosettacode.org/wiki/Boustrophedon_transform#ALGOL_6...

dgb23 4y ago

I like the notion of discriminating the general kind that names refer to with different separation styles. I think the most common are: - camelCase - PascalCase - snake_case - kebab-case - |sentence case| I think the last one can be used in CL, but not 100% sure. Some examples: - Clojure prefers kebab-case mostly, but some types and definitions use PascalCase to imply that there is a more direct mapping to a Java class. Clojure prefers to use namespaces to name things that belong together over long, prefixed names. Single letter names are common for function parameters such as 'm' for maps, 's' for strings and so on. - Go prefers camelCase for private/local types fields and functions. When PascalCase is used, then the name is exported. Go generally prefers short, often abbreviated names (Unix/C heritage). - Rust prefers PascalCase for type definitions, snake_case for function names, locals and parameter names. - Both in Go and Rust, packagas/modules/crates give additional naming structure but also control visibility. So those things have multiple jobs. So generally the-wayWe_Type/And-NameThings in different languages can give us a bit more structure and meaning without cluttering the syntax with additional keywords. A big side-benefit is that we then don't need to decide which style to use! It's better to have a uniform style than your personally preferred one IMO.

kagevf 4y ago
> I think the last one can be used in CL, but not 100% sure. You can create a symbol that way: (let ((|my symbol| 123)) |my symbol|) => 123
toastal 4y ago
If you think that last bit of wacky casing combinations is offensive, wait BEM-style CSS selectors—not the philosophy or separation of components, just the selectors themselves. Basically any other naming or separator selection would have been better.
atombender 4y ago
I never understood why some languages like Rust are so inconsistent here: snake_case for non-type identifiers, but PascalCase rather than Snake_Pascal_Case for types. Maybe OP's study is real, but the underscore has always bothered me. I'm fine with it in principle, but it creates visual noise, since pretty much all fonts put the underscore below the baseline. Here's a mockup that fixes the vertical placement of the underscore (right hand side): https://i.imgur.com/5sF3QMH.png https://i.imgur.com/5sF3QMH.png Much better!

ulizzle 4y ago

Because "normal" writing (prose) isn't code. The medium dictates the delivery.

hypertele-Xii 4y ago
Normal writing and code are both text to be read by humans. They are the same medium with regards to readability. Our brains use the same circuits we developed to read normal writing to read code. I haven't seen any evidence to the contrary.