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

Provide example of mid-variable acronym naming #2864

Closed
wants to merge 1 commit into from
Closed

Provide example of mid-variable acronym naming #2864

wants to merge 1 commit into from

Conversation

danbeam
Copy link

@danbeam danbeam commented Nov 9, 2023

Technically 23.9 says "Acronyms and initialisms should always be all uppercased, or all lowercased", however some counterexamples came up during a recent code review.

Counterexample: a variable that captures a GHE (GitHub Enterprise) API (Application Programming Interface) URL (Uniform Resource Locator) in the current rules can be (if all acronyms were to be used):

  • GHEAPIURL or
  • gheapiurl

but it seems reasonable to allow:

  • gheApiUrl

based on the spirit of "readability" (making the word boundaries clearer).

So I'm just adding an example in hopes of not really needing to change the rule but still making sense.

Technically 23.9 says "Acronyms and initialisms should always be all uppercased, or all lowercased", however some counterexamples came up during a recent code review.

Counterexample: a variable that captures a GHE (GitHub Enterprise) API (Application Programming Interface) URL (Universal Resource Locator) in the current rules can be (if all acronyms were to be used):

* `GHEAPIURL` or
* `gheapiurl`

but it seems reasonable to allow:

* `gheApiUrl`

based on the spirit of "readability" (making the word boundaries clearer).

So I'm just adding an example in hopes of not really needing to change the rule but still making sense.
@@ -3521,7 +3521,7 @@ Other Style Guides
];

// also good
const httpRequests = [
const httpUrlRequests = [
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first, let's keep httpRequests; but second, Url is literally never correct, ever, and should never appear in your code, so this would be a very bad example to provide.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately Google's style guides haven't ever been considered idiomatic by the wider ecosystem.

@ljharb
Copy link
Collaborator

ljharb commented Nov 10, 2023

iow, httpURLRequests is infinitely better than httpUrlRequests. We're not java, let's aim higher :-)

@ljharb ljharb marked this pull request as draft November 10, 2023 17:40
@danbeam
Copy link
Author

danbeam commented Nov 10, 2023

iow, httpURLRequests is infinitely better than httpUrlRequests. We're not java, let's aim higher :-)

I'm sorry I don't understand; what do "infinitely" and "aim higher" mean in this context?

@danbeam
Copy link
Author

danbeam commented Nov 10, 2023

@ljharb you requested changes; what would you like me to change?

@ljharb
Copy link
Collaborator

ljharb commented Nov 10, 2023

"aim higher" means, let's do better than Java. Url is flatly incorrect, and in JS, we should avoid it.

I don't have a concrete change to suggest; if you can think of an example of mid-variable acronym naming that doesn't improperly case an initialism then I'd be happy to consider it. If not, then it may be best to close that.

@danbeam danbeam closed this Nov 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants