Document non-code casing conventions

[rudolf]

There's currently a myriad of casing conventions without a single place that documents all of them. This makes it hard for plugins to maintain consistency. We should document these conventions and make sure that examples in documentation, example plugins and test plugins follow these conventions to avoid confusion.

Frontend app URL's / appRoute => snake_case

We should document that plugins should follow the convention of using snake_case for their app URL's.

Frontend appId => snake_case?

There doesn't seem to be a strong convention in existing code, but given that appRoute defaults to /app/${appId} it should probably be snake_case unless we change the default to something like /app/${toSnakeCase(appId)}.

Config keys => camelCase

New Config keys should be in camelCase until we refactor all config keys to snake_case in 8.0.0 #7444 (comment)

PluginId => camelCase

We have a runtime warning, but not sure if we have documentation

kibana/src/core/server/plugins/discovery/plugin_manifest_parser.ts

Line 119 in 7e32841

log.warn(`Expect plugin "id" in camelCase, but found: ${manifest.id}`);

API URL's and fields => snake_case

Already documented https://github.com/elastic/kibana/blob/master/STYLEGUIDE.md#api-endpoints

Saved Object type names => snake_case

Most types use kebab-case but since the type name forms part of the saved objects API URLs (https://www.elastic.co/guide/en/kibana/master/saved-objects-api-get.html) a better convention would be to use snake_case. Note: Changing saved object type names is not supported at the moment and would be a breaking API change, so we should not change existing types.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)