Things naming conventions

[fredck]

When coding CKEditor, several kinds of "things" need constantly to be named. We should try to uniformize these names.

This is the list of "things" to take in consideration:

• 1. Default, for things not listed here:
  • lowerCamelCase
  • singular
• 2. Repositories: lower-case with dash ("-") separators.
• 3. CKEditor specific repos: prefixed with ckeditor5-
• 4. Plugin:
  • repo: ckeditor5-plugin-pluginame
  • in-code name: lowerCamelCase
• 5. Things named as strings that are to be consumed by end-developers, like plugin names, button names, configurations, event names:
  • case-insensitive when setting and retrieving
  • when written by us: lowerCamelCase

To take in consideration: casing, separators, singular/plural

[Reinmar]

I deleted my own message... Did you receive it already on email? :P Could someone quote me? :D

[gregpabian]

Haha, alright:

For all of the names types I would use the same standard as for variable names - camelCase, no other separators. This is - buttons, plugins, commands, CSS ids, some in-code ids like ids of dialog inputs and tabs. So basically all kind of unique names fall into this category.

The exceptions are (at least currently):

CSS class names - we use underscore as separator and all lowercase. I'm to keep it or unify it.
Attribute names - we use all lowercase separated by hyphens. I would keep that because it is aligned with data-foo-bar attributes.
The singular/plural thing seems to be mostly intuitive. Though, in CKE4 we have only singular names and perhaps the reason was to keep this consistent and avoid uncertainty. When I started thinking on whether there should be "smileys" and "images" plugins or "smileys" and "image" plugins I understood why we use only singular :D I could give reasons for both of these versions. Therefore, I'm for singular names only.

[fredck]

Updated the description. The repo names may change though, depending on what we gonna use for the core code.

[wwalc]

For plugins we should seriously consider prefixing them with vendor to avoid conflicts. We already had this problem with oembed.

Today, when I wanted to ask one developer to put his plugin into the addons repository (autolink), I realized that this way we'd lose the opportunity to use the only reasonable name for such plugin, if we ever decide to create a similar plugin.

Prefixing with vendor name would not only solve the issue with us trying to create plugins for which the name is already taken, but it will also help others to provide meaningful plugin names for features that are duplicated frequently eq. foo.fileupload, bar.fileupload etc.

[adelura]

I like the idea how grunt does it:

The "grunt-contrib" namespace is reserved for tasks maintained by the Grunt team, please name your task something appropriate that avoids that naming scheme.

[fredck]

Added "5".

[fredck]

For plugins we should seriously consider prefixing them with vendor to avoid conflicts.

We're already requiring plugin repos to be prefixed with ckeditor5-plugin-. We could write documentation saying that vendor names should be appended to it. For example:

• Repo name: ckeditor5-plugin-google-fileupload
• AMD name: plugin!google-fileUpload

Then we'll keep the "vendor-less" names reserved to the CKEditor core team.

Q1: Is this idea good?

One big problem I see with this is the "no ownership" nature of OSS. Let's supposed that the above is a MIT licensed plugin and that Google decides to not maintain it further officially. Microsoft decides to keep the plugin alive and take official ownership of the project. So they'll be maintaining the "Google File Upload" plugin forever. No way! They'll just rename everything with "microsoft" and a new plugin will be born :/

We can close our eyes to this and just assume that most of the OSS projects that are not maintained simply die.

Q2: Are we ok with this?

Finally, there will be no way for us to enforce the name convention. So no one will stop you to push to npm your ckeditor5-plugin-fileupload project.

Q3: What about this?

[Reinmar]

I think that we have enough real examples now so when taking new decisions we can simply follow what we've done in the past :D.