Code Style: express acronyms in capital space

[DenisIzmaylov]

Basic requirements:

• Keep source code as documentation - lexically and grammarly correct.
• Keep signatures and API compliant with general (native) API.
• Express acronyms in capital spaces, e.g. encodeURIComponent, SIMD, decodeURI,
  JSON, NaN, URIError, cipher:setAAD and so on.
• Keep API predictable - you just know if some part in a name is acronym then write it in capital case. You should not remember where is to write acronyms in lower case, etc. That's why we've updated this pull request.

Current state:

• README:

  const jss = createJss()
  

• Probably other places (did not explored the source code deeply yet).

[lttb]

Thanks for watching!
And there is also a rule about capitalized acronyms here https://github.com/airbnb/javascript#naming--Acronyms-and-Initialisms

So we have discussed a little with @kof (#1 (comment), #1 (comment)) about this style too, and I see this way:

• use strict camelCase for everything except CONSTANTS
• use lowercase for instances, PascalCase for classes/constructors (like https://github.com/airbnb/javascript#naming--PascalCase)

[DenisIzmaylov]

This rule ( https://github.com/airbnb/javascript#naming--Acronyms-and-Initialisms ):

Acronyms and initialisms should always be all capitalized, or all lowercased.

Provides a two variants. More variants - more complexity and errors. I'd just like to see less complexity and less errors in our projects.

use lowercase for instances, PascalCase for classes/constructors

This rule is not applying for acronyms according to the rule above.

use strict camelCase for everything except CONSTANTS

As I provided the examples in the original post - native API is not satisfying to this rule.

Generally the developers asking themself in trying to write code at first time:

• What I should to write?

It means - a new custom rule will add a cognitive complexity:

• How I should to write?

P.S.

• Airbnb code style fell into the trap of popularity - they have to be more flexible, otherwise they will lose users.
• On opposite side we have to be predictable everywhere to run fast in expanding.

[iamstarkov]

I don't understand the issue

[kof]

Javascript is not consistent with that as well: for e.g. XMLHttpRequest - even in one word 2 different conventions.

Using strict version is easier, we don't need to think how to name it. Less rules apply. Its also a very popular convention, I would rather stick with this.

[iamstarkov]

me too

[kof]

Also with strictCamelCase its possible to convert from snake_case automatically. Which is often important in the applications when dealing with the http API's which are mostly written in snake.

[iamstarkov]

lets not change anything for now and re-iterate in a few months