Hm.. In RESTBase for example we don't really allow snake_case variable names, only property names. We use snake_case for configuration parameters while normal vars use camelCase

Hmm… we should make standardize on this.

@bearND any thoughts here?

I guess we need a lint rule for just the output of our services. I'm not sure if that's possible in eslint; haven't looked into this yet. It doesn't matter to me if we use camelCase or snake_case, as long as the services are somewhat consistent.

I guess we need a lint rule for just the output of our services

I don't think that's doable.

If this is a bike-shedding ticket, then my +1 goes to snake_case. C++ (still) rulez! :)

In T164098#3222169, @Fjalapeno wrote:

Hmm… we should make standardize on this.

I agree. It makes sense to have the same policy throughout our services.

The wider JS ecosystem is pretty much CamelCase only, and so is our code. Moving to mandatory snake_case in JS code would be a big change, and would put us at odds with typical JS and node.js styling.

My personal recommendation would be to stick with the current rule of

a) CamelCase for code, and
b) snake_case for configs and API parameters.

What about JSON responses?

JSON responses are currently snake_case as well. Examples: extract_html in https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_summary_title; start_time, end_time and caption_HTML in https://en.wikipedia.org/api/rest_v1/#!/Feed/get_feed_announcements

Makes sense to me... going to camel case for all projects makes sense - just wanted to make sure we were using the same conventions across projects.

Should I just close this then?

@bearND should we just try to convert to camel case over time in MCS - since it’s not a high priority?