[HN Gopher] CamelCase vs. Snake_case Scientific Studies
___________________________________________________________________
CamelCase vs. Snake_case Scientific Studies
Author : miohtama
Score : 31 points
Date : 2024-05-21 07:55 UTC (4 hours ago)
(HTM) web link (whatheco.de)
(TXT) w3m dump (whatheco.de)
| JadeNB wrote:
| And a follow-up: https://whatheco.de/2013/02/16/camelcase-vs-
| underscores-revi...
| keybored wrote:
| hyphen-case is worth the grammar concessions (like making
| whitespace between binary operators mandatory).
| dailykoder wrote:
| sPoNgEbOb-CaSe combined with hyphens is the only viable
| solution
| stock_toaster wrote:
| kebab-case and SCREAMING-KEBAB-CASE are often found in urls too
| yodon wrote:
| 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.
| eviks wrote:
| If I read figure 2 correctly (in the follow up study), the
| difference in find time only appears in 3-word names, while for
| 2-word names the time is the same
| adolph wrote:
| Ok, so I'm most definitely going to snakeCase my Hungarian
| notation from now on.
|
| https://en.wikipedia.org/wiki/Hungarian_notation
| endre wrote:
| now a study on tabs vs spaces, please
| petepete wrote:
| I find snake case so much easier to read, breathing space between
| words is there for a reason.
| montebicyclelo wrote:
| IAgreeThatSnakeCaseIsEasierToRead,ThoughIfWeWereToUseCamelCaseM
| oreWeWouldBeSavingAGoodAmountOfSpace,WhichMightBeUsefulForNarro
| wBlocksOfText.I'mSuprisedItHasn'tCaughtOnInProse.Actually,Looki
| ngAtThis,MaybeIt'sAGoodThingItHasn'tCaughtOnForProse.
| ejolto wrote:
| Classical Latin used all caps no spaces, so rather than
| caught on we moved away from it.
|
| https://en.wikipedia.org/wiki/Scriptio_continua
| martinclayton wrote:
| Title should mention that the article is from 2011.
| navane wrote:
| Why can't we just have spaces in our variable names? These are
| both work arounds.
| interstice wrote:
| Two space bars?
| bogdan wrote:
| tab where tab = 1 space
|
| Note: this is not a good idea
| reqo wrote:
| It would make languages like Python quite unreadable as it
| would be hard to distinguish between variables and keywords!
| delichon wrote:
| 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.
| rileymat2 wrote:
| 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.
| delichon wrote:
| 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.
| xmcqdpt2 wrote:
| 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()
| Just_Harry wrote:
| PowerShell yet again proves itself to be an enlightened
| language: PS> ${Valid characters for an
| identifier? Eh, -\_(tsu)_/- whatever (`}) you want.} = $True
| PS> ${Valid characters for an identifier? Eh, -\_(tsu)_/-
| whatever (`}) you want.} True
|
| Jesting aside, I have actually used that syntax before to
| prefix variable names with '&' and '@' to differentiate between
| virtual and physical addresses in some code for patching a
| binary.
| thrance wrote:
| 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 think you should follow the specific guidelines of the
| language you are currently using.
| jaynetics wrote:
| 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)...
| ChrisMarshallNY wrote:
| I use both. Depends on the context.
|
| In Swift (where I spend most of my time), it's CamelCase, or,
| quite often, dromedaryCase.
| jrpelkonen wrote:
| I've never heard of dromedaryCase. It has always been
| PascalCase vs camelCase in my circles. TIL
| j1elo wrote:
| 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.
| pavlov wrote:
| In Unicode there's the non-breaking space character. It's even
| easy to type, at least on Mac: just press Option+Spacebar.
| Glacia wrote:
| 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.
| caleblloyd wrote:
| The most peeving to me is camel case conventions that preserves
| the capitalization of abbreviations. Convention that would
| require TCPIPQOSScore instead of tcpIpQosScore.
| pekim wrote:
| 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.
| derbOac wrote:
| I use both but camel case assumes capitalization doesn't have
| meaning other than as a sort of break indicator, which isn't
| always the case.
___________________________________________________________________
(page generated 2024-05-21 12:00 UTC)