snake_case vs camelCase URL query params

[chris48s]

Over the last 10+ years we have accumulated a lot of code written by a lot of different people.
In general, I think we've done a reasonable job of enforcing relatively consistent code styles and naming conventions, via documentation and/or lint rules, but there are obviously some exceptions.

One significant "blind spot" where we have a lot of variance is whether we use snake_case or camelCase URL query params.

There's a bunch of places where we are using camelCase. For example:

shields/services/maven-metadata/maven-metadata.service.js

Lines 7 to 11 in 41d072e

	const queryParamSchema = Joi.object({
	metadataUrl: optionalUrl.required(),
	versionPrefix: Joi.string().optional(),
	versionSuffix: Joi.string().optional(),
	}).required()

shields/services/pypi/pypi-base.js

Lines 23 to 25 in 41d072e

	export const queryParamSchema = Joi.object({
	pypiBaseUrl: optionalUrl,
	}).required()

shields/services/nexus/nexus.service.js

Lines 51 to 57 in 41d072e

	const queryParamSchema = Joi.object({
	server: optionalUrl.required(),
	queryOpt: Joi.string()
	.regex(/(:[\w.]+=[^:]*)+/i)
	.optional(),
	nexusVersion: Joi.equal('2', '3'),
	}).required()

and a bunch of places where we are using snake_case. For example:

shields/services/vpm/vpm-version.service.js

Lines 6 to 9 in 41d072e

	const queryParamSchema = Joi.object({
	repository_url: optionalUrl.required(),
	include_prereleases: Joi.equal(''),
	}).required()

shields/services/gitea/gitea-last-commit.service.js

Lines 26 to 32 in 41d072e

	const queryParamSchema = Joi.object({
	path: relativeUri,
	display_timestamp: Joi.string()
	.valid(...displayEnum)
	.default('author'),
	gitea_url: optionalUrl,
	}).required()

shields/services/website-status.js

Lines 16 to 21 in 41d072e

	const queryParamSchema = Joi.object({
	up_message: Joi.string(),
	down_message: Joi.string(),
	up_color: Joi.alternatives(Joi.string(), Joi.number()),
	down_color: Joi.alternatives(Joi.string(), Joi.number()),
	}).required()

I think the other day we acquired the first case where we have one of each next to each other on the same service 🤦

shields/services/matrix/matrix.service.js

Lines 12 to 17 in 41d072e

	const queryParamSchema = Joi.object({
	server_fqdn: Joi.string().hostname(),
	fetchMode: Joi.string()
	.valid(...fetchModeEnum)
	.default('guest'),
	}).required()

I have not counted exactly, but roughly speaking we have about half and half.

The standard params that apply to all badges are all camelCase: labelColor, logoColor, logoSize

I think we've at least managed to avoid having any params that use snake-case 🤞 but maybe somewhere in the codebase there is an example 😬

There are a couple of ways we can change the names of query params without making a breaking change. One way we can do it is with redirects. Another would be to write the queryParamSchemas to accept both formats but only document one for the services where we want to fix this. Having got to the stage where we have hundreds of service integrations, this is going to be quite difficult to unpick, and I wouldn't want to do it all at once. It would be nice to gradually work towards fixing this though.

I suggest we:

1. Pick one or the other
2. Document it
3. Make some kind of a lint/danger rule to catch this
4. At least get to a stage where everything we add from now onwards matches this convention
5. Gradually bring services into line with the convention

Given:

1. We use camelCase for variable names (which makes translating URL query params straight to correctly named variables easier)
2. The standard params that apply to all badges are all camelCase: labelColor, logoColor, logoSize

I'm gong to suggest we standardise on camelCase, but I also feel like there is a reason why we used snake_case in a lot of cases, and I can't remember what it is.

[jNullj]

I think camelCase is used more around js/node devs, so thats a pro for that.
I think that snake_case is more readable but that's personal and we can't really use this as a good point, unless the whole team thinks so, in that case it would make sense.
My last point is that as it mainly visuals we might want to stick with whatever is most common in our codebase already to avoid extra work converting to one or the other

[jNullj]

I'm gong to suggest we standardise on camelCase, but I also feel like there is a reason why we used snake_case in a lot of cases, and I can't remember what it is.

Maybe it makes sense when upstream api uses snake_case?

[chris48s]

With a badge, the underlying API is something the user doesn't necessarily interact with so I don't think there's any benefit to vertical consistency with the upstream API here. I'd say horizontal consistency across badges gives more of a benefit for users in this case.