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.

Sam Beckham
  • 1,218
  • 2
  • 12
  • 23

5 Answers5

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
}
James Allardice
  • 164,175
  • 21
  • 332
  • 312
  • 5
    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. – jackocnr Mar 19 '14 at 17:14
  • 1
    @jackocnr - 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. – James Allardice Mar 19 '14 at 17:53
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

ryanabooth
  • 351
  • 2
  • 7
  • 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. – Sam Beckham Jun 21 '16 at 15:17
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.

sam
  • 76
  • 4
-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"}]*/
Aryeh Beitz
  • 1,974
  • 1
  • 22
  • 23
  • 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. – Sam Beckham Jun 20 '17 at 14:50
  • As the above user stated, this answer is regarding **ESLint** rather than **JSHint** – lacy Feb 13 '18 at 21:18
-6

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

var foo;
$.each( jsonArray, function ( i, value ) {
    if ( i === 'array_element' ) {
        foo = value;
    }
});
inchikutty
  • 5
  • 10
    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. – callumacrae Jul 08 '14 at 10:09
  • 1
    I agree , this will compromise performance. But when you contribute to open source projects you may have to give in to coding standards. – inchikutty Jul 21 '14 at 16:36
  • 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. – Aaronius Aug 22 '14 at 00:24
  • 1
    @Aaronius 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" – WickyNilliams Sep 16 '14 at 11:53
  • 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. – Flimm Aug 20 '15 at 14:49