Hacker News Reader

Comment by chrismorgan | Hacker News Reader

I'm puzzled about the switch from camelCase to snake_case for JS as shown in http://foundation.zurb.com/docs/upgrading.html#javascript-va.... The clear convention in JavaScript is camelCase, why switch away from it? (I say this as someone who in normal life using Python and Rust uses and prefers snake_case but who uses camelCase when writing JavaScript.)

View on HN

This is insane.

I have literally never seen a large-scale open source project or JS style guide that uses snake_case.

The DOM is camelCase. jQuery is camelCase. Node APIs are camelCase. Why on earth do Zurb think their library is any different?

Meteor did, at least in the beginning.

> This is insane.

Really? Why on earth would you care? What if they were to indent their code with 3 spaces? Would that be "insane", too? What if they don't like putting in unnecessary braces around one line "if" statements? Insane?

It's a (very common) stylistic choice. It's hardly insane.

It's a public API meant for consumption by other developers, 95-99% of which are going to be use camelCase.

I don't care what their code looks like internally. I do care about the public interface to it.

>What if they were to indent their code with 3 spaces?

Whoa there buddy! Put the gun down...

>What if they were to indent their code with 3 spaces?

Whoa buddy! Put down the gun...

On a serious note... is this trolling or are people seriously complaining about camel-case vs snake-case?

While I hate camelCase, i have to agree, javascript core lib uses camelCase and PascalCase , so should 3rd party libraries.

What has this site come to...

I wouldn't mind if more projects did this to be honest.

I would, just because it causes fragmentation. PEP-8[0] is a big win for Python. Javascript relies on adhoc standards and best practice docs from respected entities.

I'm open to change and debate, but it should be approached carefully.

[0]: http://www.python.org/dev/peps/pep-0008/

To be fair, at the time JS was developed, there was a body of well-documented knowledge involving camelCasing. First and foremost was, of course, Java. There are various RFCs involving LDAP schemas as well -- I recall seeing a hilarious document once describing how to properly name the attribute corresponding to an entity's certificate:

   cACertificate*

Talk about slavish consistency.

> The clear convention in JavaScript is camelCase, why switch away from it?

Citation?

Javascript was created in camelCase, and most major open source projects I've used have been camelCase. I can't find any data on it, but it fits with my experience for what that's worth.

How would you even expect this to be cited?

Seriously, does someone need to crawl every Javascript project on Github and compile statistics on naming styles before they can make an obviously true statement like this? The fact that camelCase is the norm in the language and browser environment is obvious to anyone who has written even a modest amount of JS.

   notQuantified != false

notQuantified !== false

to avoid type coercion here

S/he was using CoffeeScript, obviously! :)

> crawl every Javascript project on Github and compile statistics on naming styles

You mean... like this? http://sideeffect.kr/popularconvention/#javascript

Unfortuantely there's no stat there for camelCase for Javascript.

Let's just try some searches for some common names using github code search with a ".js" extension filter

hideImage vs hide_image: 424 vs 50

toggleItem vs toggle_item: 1022 vs 52

clickElement vs click_element: 3469 vs 368

Coding conventions by statistics :)

https://github.com/search?q=searchPage+extension%3Ajs&type=C...

> Citation?

Well, it's sure as hell not window.set_timeout, window.clear_interval, window.on_load, etc.

Suggestion:

JavaScript.

Camel cased would actually be javaScript

Idiomatic JavaScript code uses both PascalCase and camelCase.

Constructors use PascalCase; variables and methods use camelCase.

So, it's OK to call it JavaScript! :-)

Reply on news.ycombinator.com