Documentation: Coding Guidelines: Prescribe specific camelCasing behaviors

[aduth]

Related: #6741, #2511

This pull request seeks to expand upon variable naming guidelines, making it clear that WordPress' camelCasing guidelines are to be followed, with more specific treatment in Gutenberg's handling of abbreviations, acronyms, constants, and the ES2015 class construct.

Testing instructions:

There is no impact on the application.

[noisysocks]

Should we note that React function components should be UpperCamelCase as well?

[gziolo]

Just noting that we aren't consistent ourselves because we use edit and save for blocks where we should really be using Edit and Save...

[aduth]

It's a tricky one. I think the functional components should be UpperCamelCase, yes. Part of that is an expectation that it could be converted to a class component at any point. And also just for consistency. edit and save are interesting to note. They were originally meant to be "just functions", not strictly so much a component: save at one time could even just return a markup string. When we extract the component proper, we do name them "correctly" (e.g. ImageEdit). And in general a capitalized property name seems a bit strange, though I think at one point we were doing the destructure as const { edit: Edit } = blockType;. Maybe it's enough to make that distinction on declaration of variable / class, vs. property name?

[gziolo]

I think at one point we were doing the destructure as const { edit: Edit } = blockType;. Maybe it's enough to make that distinction on declaration of variable / class, vs. property name?

Yes, it makes sense. In addition we can change the way we import edit for core blocks to work as you described. I can do it as a follow-up as I introduced this shortcut 😓

[gziolo]

Nice addition 💯

[aduth]

Will plan to let this sit until after the Core JS meeting today, just in case any last-minute objections are raised.

[ntwb]

👍 👍

[aduth]

From today's Core JS meeting, I'm going to make some clarifications to beginning-of-variable naming with respect to acronyms, e.g. both let domDocument; and class DOMDocument are the expected forms and should be detailed in the guidelines as appropriate to prescribe this.

[aduth]

I added start-of-variable abbreviation naming clarification and components clarification in 8531576 and 4263e55 respectively.

[aduth]

Considering those last two additions as already having been agreed upon. Particulars of phrasing can be iterated upon in subsequent pull requests if needed.