Discuss
  • Is ES officially a PascalCase and camelCase langauge?

Is ES officially a PascalCase and camelCase langauge?

# Andrea Giammarchi (9 years ago)

I know the "what majority does" answer, yet I wonder if to avoid API fragmentation we should stick in the specification the fact that ECMAScript is a camelCase oriented programming language.

This will put an end to those coming from C, Python, Ruby, or PHP using property_name for their new API and developers will finally have a minimal guide on language naming convention.

It is backward compatible, since IIRC there are no exception to this unwritten rule in older specs or APIs, and it will hopefully grant future consistency.

It shouldn't be different from what WebIDL has already, if anything, since also WebIDL follows same convention.

Thoughts?

Best

# kdex (9 years ago)

I'd appreciate that, too, but I think the scope should be much bigger than just ES (which is hard to enforce).

Right now, we even see some deviations in certain Web APIs that are designed to interoperate with ES to some degree. See for example [1] or [2].

One of the most opposing trends (and thus maybe weirdest cases) would be the property names in web app manifests using something akin to C-style variable naming [3], i. e. underscores, all-lowercase, often using ambiguous abbreviations like dir for direction but being A-OK with spelling out background_color instead of bg_col.

I'm not saying that it's futile to incorporate the unwritten style rules into the spec, but it wouldn't "fix" misnamed Web APIs that would still appear somewhere in our code (and might make linters go nuts?).

[1] w3c/web-nfc#27 [2] w3ctag/design-principles#15 [3] www.w3.org/TR/appmanifest/#example

# Andrea Giammarchi (9 years ago)

I think background-color, as it is in CSS, works well with JSON, and backgroundColor, as it is already in JS works well as counterpart.

Whoever introduced background_color there really should rethink such decision.

This is exactly the kind of shenanigans I'd like to see disappearing once we have a clear "it's either quoted 'background-color' or backgroundColor for properties and never 'background_color'".

How difficult could this be?

# kdex (9 years ago)

As for the Web APIs, this should be (and has been) filed with the corresponding APIs. Specifically for the Web Manifest spec, you might want to check [1] and [2] (there's even a few comments on background-color).

(tl;dr: W3C says: "There are now about ~50000 sites using manifests, it's too late to make these kinds of changes" and "We eff'ed up, and gotta live with it.")

Rants aside, since this mailing list is really just scoped to ES, I think it's worth bringing up that many languages handle this differently.

Languages that define a set of coding standards are sparse; there are many where every framework uses its own guidelines (like PHP with Zend, PEAR, …). Some appear to recommend some non-normative guidelines (like C# [3]) while others do in fact maintain official documents stating their coding conventions, like Rust [4] and Python [5].

[1] w3c/manifest#72 [2] w3c/manifest#7 [3] msdn.microsoft.com/en-us/library/ff926074.aspx [4] doc.rust-lang.org/style/style/naming/README.html [5] www.python.org/dev/peps/pep-0008

# Andrea Giammarchi (9 years ago)

All I am saying is that this "We eff'ed up, and gotta live with it." is exactly what I'd like to avoid from now on.

If tomorrow NodeList instances would implement list.for_each method instead of forEach, basically nobody can complain as it is now, which is kinda embarrassing. That's just an example, the proposal is also already about forEach, but then why wouldn't we formalize that on specs?

At least as suggested naming convention guideline.

Best