Rules for script service naming

Hello everyone,

I’m opening this brainstorming to try defining some rules related to the naming of script services.
The discussion started with a feedback from @mflorea on one of my PR because I used a lowercase script service name, while Marius was expecting a camelcase name.

When I checked our existing script services it appears that right now, only two of them are using camelcase:

  • $services.messageStream
  • $services.liveData

while we have several ones in lowercase, e.g.:

  • $services.officeimporter
  • $services.modelvalidation
  • $services.linkchecker

So would be great first to decide if we prefer lowercase or camelcase for those names, and then to document all the rules for script service names. IMO it should include the fact that a SS name should be a single word. Not sure if there’s other rule that we must explicit?


Obvious +1 for camel case. Posting my comment from GitHub:

For me camel case is the obvious choice. It doesn’t make any sense to camel case the method name (uploadTemporaryAttachment) and variable names ($temporaryAttachmentSupported) but not the “field” name (temporaryAttachments). The fact that temporaryAttachments is a component hint is an implementation detail (and in any case the component hint is case sensitive and camel cased component hints are easier to read than lower case). From the point of view of the developer using the API and reading the code using lower case is inconsistent and makes the code harder to read.


+1 for camelcase

I would actually suggest to simply follow our Java field codestyle/specification (including characters which are technically forbidden in a Java field name since they are the same which might mess with various scripting languages like [, {, etc.).

We should also probably add a note related to sub SS (e.g. security.authentication).

+1 for camelcase

+1 for:

  • single word as much as possible, and in lowercase
  • camelCase otherwise with a first letter in lowercase

Regarding $services.temporaryAttachments, I think I’d look at implementing a temporary Script Service with a sub service for attachments, as in $services.temporary.attachments (or $services.tmp.attachments) instead.