Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming conventions - Preferencing snake_case over camelCase is unnecessary #40

Closed
TimGoodwill opened this issue Aug 5, 2020 · 1 comment

Comments

@TimGoodwill
Copy link

TimGoodwill commented Aug 5, 2020

Preferencing snake_case over camelCase is an odd choice, and unnecessary. Preference will largely come down to the technology stack – CamelCase for Java/JavaScript and snake_case for Python/Ruby. In terms of common usage, the weight is with camelCase at this point in time. Several federal departments/agencies currently mandate the use of camelCase for member/field names. As per the JSON-API, restfulapi.net, google and Microsoft guidance and JavaScript standard convention (https://www.w3schools.com/js/js_conventions.asp).
It is suggested that the naming conventions should be reworded to remove any explicit preference of one convention over the other.
Additionally, the text should be reworded to refer to "case" explicitly, rather than 'message format', and stress consistency.

Suggested change:

Message Format
For request and response body field names and query parameter names case MUST be consistent, and SHOULD be either camelCase OR snake_case:

Examples:

// thisIsCamelCase

{
  "employeeId" : "AB1837"
}
// this_is_snake_case

{
  "employee_id" : "AB1837"
}

Fields that represent arrays SHOULD be named using plural nouns (e.g. products - contains one or more products).
The object and field definition must be the same for the request and response body as well as corresponding query parameters.

@TimGoodwill TimGoodwill changed the title Naming conventions - preferencing snake_case over camelCase is unnecessary Naming conventions - Preferencing snake_case over camelCase is unnecessary Aug 6, 2020
@TimGoodwill
Copy link
Author

Addressed by PR #51

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant