Camelcase issue with JSON object from outer source and Object Matching Shorthand Notation.

[NightfallAlicorn]

I don't know if I should add an ignore comment to the code or mention it here. I did a search but nothing came up.

const {
  example_property1,
  example_property2,
  example_property3
} = result.someJSON

if (example_property1) {
  // ...
}

Visual Studio Code brings up this message "[standard] Identifier 'example_property1' is not in camel case. (camelcase)". However the someJSON is from an external source through https.request and I'm trying to keep my script short and simple.

Another solution is:

const exampleProperty1 = result.someJSON.example_property1
const exampleProperty2 = result.someJSON.example_property2
const exampleProperty3 = result.someJSON.example_property3

This result feels bloated. My actual script has 17 lines to declare.

Maybe allow Object Matching Shorthand Notation to allow external JSON decorations as long as they weren't declared in the current file?

[timoxley]

@NightfallAlicorn For cases like this I just disable the camelcase rule: https://github.com/standard/standard#how-do-i-hide-a-certain-warning

[LinusU]

The idea with the rule is to not have any local variables not named in camel-case. I think that this would be the best approach:

const {
  example_property1: exampleProperty1,
  example_property2: exampleProperty2,
  example_property3: exampleProperty3
} = result.someJSON

[bcomnes]

You can also disable the rule for the file or use the destructuring trick. The go JSON encoder is doing this again, isn't it >:[

[NightfallAlicorn]

const {
  example_property1,
  example_property2,
  example_property3
} = result.someJSON

this.emit('someEvent', example_property1)

It seems fine if it's put it in a function param.

Thanks for your suggestions, guys.

[indiesquidge]

I agree with @NightfallAlicorn that this rule seems to become a nuisance when dealing with API objects.

I could live with providing a name for the variables (e.g. #985 (comment)), but on top of @NightfallAlicorn's example of passing the destructured variable directly to a function, I would also like to consider the case when variables are destructured because you don't want to use them at all

const { example_property1, example_property2, ...rest } = result.someJSON

What if my only intent is to use the rest object here, and ignore example_property1 and example_property2?

Yes, I could add variable names for the first properties, but that seems to send a confusing message to people reading this code later on: why am I giving these variables names if I do not plan on using them?

I will simply add a comment to disable Standard for this part of my code for now, but it seems like there is more than one case in which this strict of a rule need not apply.

[LinusU]

A common pattern is to name unused variables with underscores, and as far as I know standard won't complain when the name is only underscores, this something like this should work and will signal the intent clearly.

const { example_property1: _, example_property2: __, ...rest } = result.someJSON

Not saying it's the best solution though, but I'm not sure that I like creating variables that aren't used either. This is very neat in Rust where _ means "not used" in the language, and can be used multiple times in the same scope, and doesn't create the actual variable...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.