Ignore camelcase variable in JSHint
Asked Answered
L

5

66

Having a bit of an issue with JShint and the following line of code.

$location.path('map-' + map.id + '/venue-' + map.attributes.default_venue.value);

I'm getting the error, Identifier 'default_venue' is not in camel case. This wouldn't be a problem normally but I don't have any control over the variable name - it's brought in via a JSON API.

Is there any way I could suppress this issue for either the affected variables or on the lines in which they appear?

Apologies if this has been asked before, I'm pretty sure it must have been but I can't find a solution.

Languor answered 18/10, 2013 at 11:20 Comment(0)
U
130

JSHint obeys directives at a function level, so you can find the enclosing function and add a camelcase option to it. Here's an example:

/*jshint camelcase: true */

var not_camel_case = 1; // Warns

function example() {
  /*jshint camelcase: false */
  var not_camel_case = 2; // Does not warn
}
Uzbek answered 18/10, 2013 at 11:52 Comment(2)
This is a great answer, but is not really scalable. If everything you fetch from the API contains underscores then you're not going to add this comment in every single place where you use that data. I've resigned myself to the fact that if your API doesn't use camel case, then it's not worth trying to enforce it in your front-end code.Spartacus
@Spartacus - Yeah if you're having to deal with a lot of underscored property names from somewhere there is no way to differentiate between them and the ones you define in your own code. Short of patching JSHint to allow a list of "underscore allowed" identifiers there isn't really a way around that.Uzbek
P
19

According to the JSHint Docs, you can make a config file in the same directory called .jshintrc, or any directory all the way to your root directory. I just set mine using this:

  {
    "camelcase": false
  }

There are loads of other options here: http://jshint.com/docs/options/#camelcase

Prompt answered 27/8, 2014 at 8:11 Comment(1)
This is fine if you want to include it for every line of code. I just wanted it for the one line where I needed to override it. See the accepted answer for how to do this.Languor
C
4

I put the name of the property coming from the api in a separate string. E.g.:

var defaultVenueAttributeKey = 'default_venue';
$location.path('map-' + map.id + '/venue-' + map.attributes[defaultVenueAttributeKey].value);

It's a bit more verbose but you could group all property names coming from your API together and then it makes responding to the API changing easier.

Circlet answered 18/11, 2014 at 15:41 Comment(0)
W
-1

The accepted answer /*jshint camelcase: true */ didn't work for me. I was still getting the errors.

I looks at the docs and found this solution that worked for me:

/*eslint camelcase: ["error", {properties: "never"}]*/
Wizened answered 18/6, 2017 at 7:26 Comment(2)
This question is regarding jsHint, your answer is regarding esLint. They are different things that serve a similar purpose. Though your answer is the correct one for esLint.Languor
As the above user stated, this answer is regarding ESLint rather than JSHintHensel
W
-6

Try out something like this.. Though wicked, it will work.

var foo;
$.each( jsonArray, function ( i, value ) {
    if ( i === 'array_element' ) {
        foo = value;
    }
});
Windbound answered 30/6, 2014 at 11:38 Comment(5)
No, please don't do that! That is not an efficient way to get a property from an object, and sacrificing performance in the name of coding standards is generally a bad idea.Aviary
I agree , this will compromise performance. But when you contribute to open source projects you may have to give in to coding standards.Windbound
Is this just to try to get around linting? If that's the case, why not just do jsonArray['array_element']? Either way, no...just don't.Lipscomb
@Lipscomb funnily, jshint complains in these situations if you try to try to access the property as a string, claiming something along the lines of "would be better accessed with dot operator"Corona
The point of a linter is to make code more readable, among other things, this really doesn't. Clever solution but it's a little bit too clever.Functionary

© 2022 - 2024 — McMap. All rights reserved.