Is ES officially a PascalCase and camelCase langauge?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Is ES officially a PascalCase and camelCase langauge?

Andrea Giammarchi-2
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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Is ES officially a PascalCase and camelCase langauge?

kdex
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
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Is ES officially a PascalCase and camelCase langauge?

Andrea Giammarchi-2
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?

Regards



On Tue, Jun 28, 2016 at 9:58 AM, kdex <[hidden email]> wrote:
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
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Is ES officially a PascalCase and camelCase langauge?

kdex
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] https://github.com/w3c/manifest/issues/72
[2] https://github.com/w3c/manifest/issues/7
[3] https://msdn.microsoft.com/en-us/library/ff926074.aspx
[4] https://doc.rust-lang.org/style/style/naming/README.html
[5] https://www.python.org/dev/peps/pep-0008/


On Dienstag, 28. Juni 2016 11:41:43 CEST Andrea Giammarchi wrote:

> 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?
>
> Regards
>
>
>
> On Tue, Jun 28, 2016 at 9:58 AM, kdex <[hidden email]> wrote:
>
> > 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
> > >
> >
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Is ES officially a PascalCase and camelCase langauge?

Andrea Giammarchi-2
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 Regards

On Tue, Jun 28, 2016 at 12:34 PM, kdex <[hidden email]> wrote:
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] https://github.com/w3c/manifest/issues/72
[2] https://github.com/w3c/manifest/issues/7
[3] https://msdn.microsoft.com/en-us/library/ff926074.aspx
[4] https://doc.rust-lang.org/style/style/naming/README.html
[5] https://www.python.org/dev/peps/pep-0008/


On Dienstag, 28. Juni 2016 11:41:43 CEST Andrea Giammarchi wrote:
> 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?
>
> Regards
>
>
>
> On Tue, Jun 28, 2016 at 9:58 AM, kdex <[hidden email]> wrote:
>
> > 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
> > >
> >
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss