Update documentation for coding style and camelCase usage

CONTRIBUTING.md

@@ -135,6 +135,11 @@ Prettier before a commit by default.
 
 [integrate prettier]: https://prettier.io/docs/en/editors.html
 
+### Coding style
+
+This project uses camelCase for variable names and function names and client facing parameters.
+We use PascalCase for class names and service names.
+
 ### Tests
 
 When adding or changing a service [please write tests][service-tests], and ensure the [title of your Pull Requests follows the required conventions](#running-service-tests-in-pull-requests) to ensure your tests are executed.

doc/TUTORIAL.md

@@ -107,7 +107,7 @@ Other classes implement useful behavior on top of [BaseService].
 
 [baseservice]: https://contributing.shields.io/module-core_base-service_base.html
 
-As a first step we will look at the code for an example which generates a badge without contacting an API.
+As a first step we will look at the code for an example which generates a badge without contacting an API. Note that camelCase should be used for variables, functions, and path/query parameters.
 
 ```js
 // (1)
@@ -346,6 +346,8 @@ export default class GemVersion extends BaseJsonService {
 
    but we have used the helper function `pathParams` to imply some defaults and reduce the amount of code we need to write by hand.
 
+7. Path and query parameters should be camelCase, for example use `gemName` instead of `gem_name`.
+
 Save, run `npm start`, and you can see it [locally](http://127.0.0.1:3000/).
 
 If you update `openApi`, you don't have to restart the server. Run `npm run prestart` in another terminal window and the frontend will update.

doc/badge-urls.md

@@ -6,13 +6,14 @@
 - The `NOUN` part of the route is:
   - singular if the badge message represents a single entity, such as the current status of a build (e.g: `/build`), or a more abstract or aggregate representation of the thing (e.g.: `/coverage`, `/quality`)
   - plural if there are (or may) be many of the thing (e.g: `/dependencies`, `/stars`)
-- Parameters should always be part of the route if they are required to display a badge e.g: `:packageName`.
+- Parameters should always be part of the route if they are required to display a badge e.g: `:packageName` and should be camelCase.
 - Common optional params like, `:branch` or `:tag` should also be passed as part of the route.
 - Query string parameters should be used when:
   - The parameter is related to formatting. e.g: `/appveyor/tests/:user/:repo?compact_message`.
   - The parameter is for an uncommon optional attribute, like an alternate registry URL.
   - The parameter triggers application of alternative logic, like version semantics. e.g: `/github/v/tag/:user/:repo?sort=semver`.
   - Services which require a url/hostname parameter always should use a query string parameter to accept that value. e.g: `/discourse/topics?server=https://meta.discourse.org`.
+  - Similar to parameters, query string parameters should be camelCase e.g: 'labelColor' and not 'label_color'.
 
 It is convention to use the following standard routes and abbreviations across services: