Live data from Hacker News

CamelCase vs underscores: Scientific showdown (2011)

whatheco.de

81–90 of 138 posts

Re: CamelCase vs underscores: Scientific showdown (2011)

#81

my favorite thing about camelCase is that class instances are (typically) named and cased as the inverse of their pascal-cased class. val somethingRepository = SomethingRepository() Is much more visually satisfying and balanced to me than: something_repository = SomethingRepository()

I like the latter much more. I can come up with rationalizations, like my eyes having to travel to the beginning of the long identifiers if I want to tell instance and class apart in the first example but not in the second.

But honestly it’s most likely because I was socialized on Python. Feeling lucky personally that Rust follows the same convention.

Re: CamelCase vs underscores: Scientific showdown (2011)

#82
post #76

Earlier quoted context omitted.

I still think the space adds more readability than the dot dectracts. If you don't like the dot though, I would use a comma. We have been writing for a couple centuries now, and the comma is well known and used. search result := users, find all by name (name) if search result, is present() { return ok(search result, get()) } else { return not found() }

I have to confess I rather like that comma!

Then we could use . instead of ; for line endings, and we're almost writing prose :)

Re: CamelCase vs underscores: Scientific showdown (2011)

#83
post #76

Earlier quoted context omitted.

Using something else than a dot is better, same as using a slightly different syntax: search result := users @ find all by name (name) if search result @ is present() { return ok(search result @ get()) } else { return not found() }

I still think the space adds more readability than the dot dectracts. If you don't like the dot though, I would use a comma. We have been writing for a couple centuries now, and the comma is well known and used. search result := users, find all by name (name) if search result, is present() { return ok(search result, get()) } else { return not found() }

Few more improvements:

   // comma is optional, used for disambiguation
   search result := users, find all by name. // omitted parameters match words

   if search result is present,  // empty brackets can be omitted
      return ok(search result value); // API change for better readability 
   else
      return: not found. // colon is another optional delimiter 
 
I actually like it so much, I would try to write a transpiler to Java…

Re: CamelCase vs underscores: Scientific showdown (2011)

#84
By sheer coincidence, I was talking about this only a few days ago, and it also jogged my memory so that I reviewed a 2013 rust-dev thread on Java versus .NET conventions for type names, which differ in handling of acronyms: .NET style goes Gc and HttpServer; while Java goes GC, HTTPServer. As for XMLHttpRequest… ugh, that thing’s a menace.

My suggestion:

> There seems to be a basic assumption of ASCII identifiers. Hey, this ain't the eighties!

> Let's have us an XᴍʟHᴛᴛᴘRequest. Absolutely clear with no scope for misunderstanding in either direction: Gᴄ; Rᴄ; Aʀᴄ; SimpleHᴛᴛᴘServer.

> Monospace font support is a little poor, but I'm sure they'll fix that up once the desire is demonstrated.

> Q and X don't have small-caps variants in Unicode, so acronyms will be banned from having a Q or an X in the middle.

(My email wasn’t just trolling; I also added meaningful arguments in both directions to the discussion. But small caps was just too fun a concept to not mention. I also notice that Unicode 11 in 2018 added U+A7AF "ꞯ" LATIN LETTER SMALL CAPITAL Q for some reason (subhead “Letter for Japanese phonemic transcription” and I haven’t looked any deeper), but there’s still no small caps X.)

I’m glad to say that Rust stuck with the .NET rather than Java style—it’s easier to reason about, apart from anything else, because of having fairly unambiguous rules, and supports tooling better in a similar way to snake_case, because of unambiguous word separation. I’m also glad that no one ever challenged Rust’s use of snake_case for variables and fields and such.

Re: CamelCase vs underscores: Scientific showdown (2011)

#85

Earlier quoted context omitted.

Yeah no thanks. Soo `a-b` and `a - b` are both potentially valid and different? 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 m…

> Yeah no thanks. Soo `a-b` and `a - b` are both potentially valid and different? Like what the sibling comment said: `-b` should be illegal. And I don’t think this would be a big deal in practice for experienced users (used to these rules). For beginners you could build in an error check: give a dedicated error message if you write `a-b` but you happen to have both variables `a` and `b`. Then the compiler can tell t…

> `-b` should be illegal

Sure... but I didn't use `-b`. Maybe I've misunderstood.

> give a dedicated error message if you write `a-b` but you happen to have both variables `a` and `b`

I guess, though the idea of having mutually exclusive sets of identifiers sounds like a nightmare. You can have `a` and `a-b`, or `a` and `b`, but not `a`, `b` and `a-b`... Maybe it wouldn't come up much in practice but it's still a pretty big WTF.

> In turn you have a bidirectional translator.

But the problem is that you have this translation in the first place. It makes the identifier ungreppable. Ideally any place you have an identifier it looks exactly the same through your whole codebase and if you have to translate it then that is no longer true. For example if you want to update all background colours in your project you might search for `background-color`... but miss `backgroundColor`.

Re: CamelCase vs underscores: Scientific showdown (2011)

#87
Related:

CamelCase vs. underscores: Scientific showdown - https://news.ycombinator.com/item?id=9138156 - March 2015 (57 comments)

CamelCase vs underscores: Scientific showdown - https://news.ycombinator.com/item?id=5224531 - Feb 2013 (6 comments)

Also:

CamelCase vs. underscores revisited (2013) - https://news.ycombinator.com/item?id=34525139 - Jan 2023 (257 comments)

Re: CamelCase vs underscores: Scientific showdown (2011)

#88
post #4

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.

that’s interesting to me. For me it’s a left pinky-right ring finger move. We probably have different keyboard sizes, afaik.

Re: CamelCase vs underscores: Scientific showdown (2011)

#89
post #52
post #30

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.

Behold this monstrosity: devDbUrl Madness. The only thing worse that developers willingly tolerate is prettier's sacrilegious linebreaks [0]. 0: https://prettier.io/playground/#N4Igxg9gdgLgprEAuc0DOMAEBXNc...

JFC preach! This shits me to tears, I need to figure out a way to turn those line breaks off.

Re: CamelCase vs underscores: Scientific showdown (2011)

#90
post #4

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.

Apparently I type underscore with a chord on my right hand, pinky on right-shift and middle-finger up to underscore. I never noticed before your comment.
Post reply on HN