Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Add rules for prohibiting unused vars/expressions #78

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

haroldtreen
Copy link
Contributor

Add no-unused-* rules

Status: Ready for Review
Reviewers: @jansepar @donnielrt @marlowpayne

Changes:

  • Add rules for no-unused-variables and no-unused-expressions

I have found these rules especially useful when they detect imports I don't use:
eg.

define(['somethingUsed', 'somethingUnused'], function(used, unused) { // Linting error!
      used();
});

// OR

var used = require('used');
var unused = require('unused'); // Linting error!

used();

@jansepar
Copy link
Contributor

3am commits to the code style repo. Welcome fellow night time coder :)

:+1 thx Harold!

@marlowpayne
Copy link

Dang you guys be crazy with late night commits.

I'm wondering if these rules would break a common convention we sometimes use where we require in, but don't end up using the var for anything except side effects. For example selector-utils, or Deckard:

define([
    '$',
    'fastclick',
    'deckard'
],
function(
    $,
    fastclick
) {
    var globalUI = function() {
...

Also, these new rules should probably be run against a newly generated Adaptive project to check if anything needs updating in the generator to conform to the new ruleset.

@jansepar
Copy link
Contributor

For the ones we bring in just for side effects, we shouldn't make an argument variable for it, and if we stick to that the linter should be fine. Like in you example above, we have no argument in the callback for deckard.

+1 to testing it in a newly generated project!

@haroldtreen
Copy link
Contributor Author

Who can sleep when there may be unused variables in the wild!
Testing on a generated project sounds good! I shall do that.

As for side effect imports, Shawn's suggestion would work. I also wonder if the pattern of importing things to change the state of the world is good. Is there a way to make it more explicit that those packages are needed and do stuff?

Eg.

define([
    '$',
    'fastclick',
    'deckard'
], function($, fastclick, loadDeckard) { 
     loadDeckard();
});

Probably not a backwards compatible change, but I wonder if that would be a better system for future plugins.

@jansepar
Copy link
Contributor

Totally - I think as much as possible libraries should be built as modules
that are side-effect less until invoked. We should change this for Deckard,
as we have done for many libraries of the past, such as capturing, the
Mobify Tag, etc. Unfortunately we don't own every library we use, so for
those that don't conform to a module system, we will have to just ensure we
don't put argument variables for them to conform to the style guide.
On Sat, Nov 14, 2015 at 11:53 AM Harold Treen [email protected]
wrote:

Who can sleep when there may be unused variables in the wild!
Testing on a generated project sounds good! I shall do that.

As for side effect imports, Shawn's suggestion would work. I also wonder
if the pattern of importing things to change the state of the world is
good. Is there a way to make it more explicit that those packages are
needed and do stuff?

Eg.

define([
'$',
'fastclick',
'deckard'

], function($, fastclick, loadDeckard) {
loadDeckard();
});

Probably not a backwards compatible change, but I wonder if that would be
a better system for future plugins.


Reply to this email directly or view it on GitHub
#78 (comment)
.

// Bad: Many of these variables/expressions are useless
{} // object - not used
var newArray = []; // newArray - not used
['1', '2', '3', '4'].forEach(function(num, index) { // index - not used
Copy link
Contributor

Choose a reason for hiding this comment

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

What about when something you need is in the second argument? Say we wanted index but not num - a functional programming common practice is to use _ in it's place, but will the linter complain about that? If so I don't think we should add it to the linting rules.

Copy link
Contributor

Choose a reason for hiding this comment

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

@jansepar There are options to eslint we can use to ignore unused arguments to functions. That seems like it'd be a pragmatic compromise here.

"no-unused-vars": [2, {"vars": "all", "args": "none" }]

Reference: https://github.com/eslint/eslint/blob/master/docs/rules/no-unused-vars.md

Interestingly, I have no idea what the 2 is for in the array. All examples used 2 and the docs don't say what it's for. 😕

Choose a reason for hiding this comment

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

@jeremywiebe The 2 indicates that a rule violation will surface an error (exit code of 1) instead of just a warning.

http://eslint.org/docs/user-guide/configuring#configuring-rules

@benlast
Copy link
Contributor

benlast commented Jan 18, 2016

👍 to using eslint to enforce this and related issues. We've found it very useful on Pusheen.


// Disallow unused variables/expressions
"no-unused-vars": 2,
"no-unused-expressions": 2

Choose a reason for hiding this comment

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

I would suggest to allow the use of short circuits and ternary conditionals, since I see those a lot.

"no-unused-expressions": [2, { allowShortCircuit: true, allowTernary: true }]

@marlowpayne
Copy link

Even with options passed to both rules, a newly generated Adaptive.js project has JS lints. We should investigate what we need to change in our boilerplate code before we merge this.

@marlowpayne marlowpayne mentioned this pull request Aug 3, 2016
3 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants