Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I suspect the real reason is the same reason why you wrote "kebab-case" and "lisp-land" and not "kebab_case" and "lisp_land".

The main flaw is that the underscore is not actually a character in the English typographical language; it's a typewriter feature for going back and underlining text.

When used for joining words, it looks terrible, like a hyphen that has lost its suspenders and fallen to the floor.

I would write kebab case even if hyphen required the shift, and underscore didn't.



`kebab-case` isn't perfect. It works just fine in a prefix notated language such as LISP, but less so in an infix language. I suppose you could require significant whitespace to differentiate `a-b` from `a - b`, but even that is a little counterintuitive to read. `snake_case` is popular in both Python and Ruby, and canonical in the former. Moreover, it's canonical in SQL. Frankly, even though I like the idea of kebab casing, without the ecosystem around it changing, I have historically just apathetically accepted camelCase and snake_case, and despite being a Python lover at my core, I've gravitated more and more to camelCase as time has gone on because I definitely do find capitalization easier to parse than hyphens or underscores. I like it for the same reason I like significant whitespace. Yes, it's more painful to parse and design a language around, but it's that much closer to pseudocode.


a - b certainly isn't counterintuitive to read, and neither is max-pos - cur-pos.


But is max-pos - cur-pos better to read than maxPos - minPos or max_pos - cur_pos? I would say no to both cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: