Consistent naming for enterprise & organization scoped functions

[stevehipwell]

I'd like to see a consistent naming convention used for enterprise and organization scoped functions that reflects the significance of the scoping. My suggestion is that we adopt the pattern <VERB><SCOPE><SUBJECT> which as a very simple example would look something like GetOrganizationThing. Scope and subject are an overlapping concept so we will need to define valid scopes that are linear (possibly just enterprise and organization). Subject is a more of an art than a science but we will still want to keep the most significant information at the beginning of the function name.

As an example of an alternative but supporting pattern; in a greenfield API design these scopes could have been structural with a pattern such as client.organization.GetThing instead of client.GetOrganizationThing.

[zyfy29]

1. I agree that a consistent naming convention is needed. Currently, we see variations like GetThingInOrg, GetThingOrg, and GetOrgThing everywhere. The <VERB><SCOPE><SUBJECT> pattern seems like a good choice.

2. Regarding scope names, I'd like to discuss the following:

   • Should Org be used as an alias for Organization in function names? I would suggest not.
   • For user/repo scopes, should we omit the scope name and simply use GetThing?

3. In a greenfield API design, these scopes could have been structural, following a pattern like client.organization.GetThing instead of client.GetOrganizationThing.

   In our current case, most functions are called as client.SomeService.GetOrganizationThing. This could be a bit confusing given the existing OrganizationsService. I think deciding the order of scope and subject should be sufficient.

[stevehipwell]

In our current case, most functions are called as client.SomeService.GetOrganizationThing. This could be a bit confusing given the existing OrganizationsService. I think deciding the order of scope and subject should be sufficient.

@zyfy29 my point was that if this was a greenfield, which it isn't, we could have modeled the API as client.SomeService.GetThing & client.Organization.SomeService.GetThing.