Is ES officially a PascalCase and camelCase langauge?

kdex kdex at kdex.de
Tue Jun 28 08:58:59 UTC 2016


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] https://github.com/w3c/web-nfc/issues/27
[2] https://github.com/w3ctag/design-principles/issues/15#issuecomment-115113438
[3] https://www.w3.org/TR/appmanifest/#example-manifest

On Dienstag, 28. Juni 2016 08:14:14 CEST Andrea Giammarchi wrote:
> 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 Regards
> 


More information about the es-discuss mailing list