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

Rule suggestion: no variable declarations and assignments together [$50] #2606

Closed
bedney opened this issue May 23, 2015 · 17 comments

Comments

Projects
None yet
7 participants
@bedney
Copy link

commented May 23, 2015

I am wanting a (stylistic) rule where this would be disallowed:

var x = 2;

But this is fine:

var x;
x = 2;

In other words, variable declarations and variable assignments have to be broken into 2 pieces.

Is there already such a rule and I missed it?

Thanks!

Did you help close this issue? Go claim the $50 bounty on Bountysource.

@ilyavolodin ilyavolodin added the triage label May 23, 2015

@gyandeeps

This comment has been minimized.

Copy link
Member

commented May 24, 2015

I dont think so if we have a rule for your use case. You can also check if there is any plugin which satisfies your use case here: https://www.npmjs.com/search?q=eslintplugin

@bedney

This comment has been minimized.

Copy link
Author

commented May 24, 2015

I checked for a plugin and it doesn't seem like there is one for this.

@xjamundx

This comment has been minimized.

Copy link
Contributor

commented May 24, 2015

There are a number of options on the one-var rule that give us part of what is wanted here. Some variation of { uninitialized: "always", initialized: "never" } is sort-of what you want. It's like you're asking for {unitialized: "always", initialized: "no-really-not-ever" } :)

@bedney

This comment has been minimized.

Copy link
Author

commented May 24, 2015

Yea, I guess that's true. It seems to me like the one-var rule is already getting crowded with options, though.

@xjamundx

This comment has been minimized.

Copy link
Contributor

commented May 25, 2015

Agreed it's crowded, but mostly because of let and const. I think it's still the correct location for such a restriction. We'll have to wait and see what other team members think though before deciding if it's something we're able to add.

In the meantime, feel free to tweak the existing rule to meet your needs and distribute that as a plugin :)

@bedney

This comment has been minimized.

Copy link
Author

commented May 25, 2015

I will respectfully disagree, mainly because of the name. one-var makes sense to me when discussing 'should there be one var statement to configure the locals for this function?'. But as more features get jammed into this rule, it seems to drift further and further away from the meaning imparted by that name. Maybe these other features should be split out into a rule that would be more appropriately named?

@nzakas

This comment has been minimized.

Copy link
Member

commented May 28, 2015

This would have to be a separate rule. At the moment, new rules are very low priority as we move towards 1.0.0. Your best bet is to create the rule yourself, or else it could be a while.

@ilyavolodin ilyavolodin added rule accepted and removed triage labels May 29, 2015

@bedney

This comment has been minimized.

Copy link
Author

commented Jun 15, 2015

I've put a bounty on this bug via BountySource if anyone with the necessary set of skills (which I don't have) wants to take it on.

I have no idea what we call this rule, but I'd like something that's consistent with all of the other rule naming. Maybe @nzakas or @ilyavolodin or @xjamundx have ideas here...

My acceptance criteria is that when this rule is set to 'always' (or 'never', depending on how we name the rule), these kinds of statements are disallowed:

var x=2, y=3, z=4;
var x=2;
var y=3;
var z=4;

and only these are acceptable (ignore the formatting here - I don't really care about whether things are on separate lines or whatever - that's up to the "onevar" rule or other rules - the main thing is that you cannot both declare and define all in one statement):

var x, y, z;

and then:

x = 2; y =3; z=4;

Conversely, the setting opposite to 'always' or 'never' allows this form and disallows what I describe above.

I'm open to suggestions and comments here (in fact, I'd love them!)

Thanks!

@ilyavolodin

This comment has been minimized.

Copy link
Member

commented Jun 15, 2015

Should this rule error on the following code:

for (var i = 0, l = array.length; i < l; i++) {
    ...
}

How about the following code:

var myFunc = function() {
    ...
}

@ilyavolodin ilyavolodin added the bounty label Jun 15, 2015

@ilyavolodin ilyavolodin changed the title Rule suggestion: no variable declarations and assignments together Rule suggestion: no variable declarations and assignments together [$50] Jun 15, 2015

@bedney

This comment has been minimized.

Copy link
Author

commented Jun 15, 2015

Most definitely yes! and yes! My focus for this rule is that you should never (or should always) do both the declaration and the definition of a variable together.

@btmills

This comment has been minimized.

Copy link
Member

commented Jun 15, 2015

Perhaps initialize-declarations with options "always" or "never"? (The "never" mode would of course not report const declarations.)

@ilyavolodin

This comment has been minimized.

Copy link
Member

commented Jun 15, 2015

I would shrink the name down to init-declarations but I think that should work, even though it's a bit vague.

@bedney

This comment has been minimized.

Copy link
Author

commented Jun 15, 2015

Another suggestion (which I'm not in love with, but I'll throw it out there):

split-declarations-from-definitions

@nzakas

This comment has been minimized.

Copy link
Member

commented Jun 15, 2015

+1 for init-declarations

@bedney

This comment has been minimized.

Copy link
Author

commented Jun 16, 2015

Ok, so init-declarations sounds good to me. Given that name, I would assume the behavior I'm looking for would be the 'never' setting. Also, I agree that 'never' should ignore 'const' declarations, but I think that 'let' should be included in the rule along with 'var'.

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 29, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 29, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 29, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 29, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 29, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 30, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 30, 2015

cjihrig added a commit to cjihrig/eslint that referenced this issue Jun 30, 2015

@btmills btmills closed this in #2869 Jul 1, 2015

btmills added a commit that referenced this issue Jul 1, 2015

Merge pull request #2869 from cjihrig/init-decls
New: Add init-declarations rule (fixes #2606)
@Berkmann18

This comment has been minimized.

Copy link

commented May 19, 2016

Sorry for the bump.
I keep getting "Split into declaration and initialization" warnings (which I don't want) but according to this thread the rules which are init-declarations and one-var but both are off, why is that happening ?

@ilyavolodin

This comment has been minimized.

Copy link
Member

commented May 19, 2016

@Berkmann18 Please open a new issue.

@eslint eslint bot locked and limited conversation to collaborators Feb 7, 2018

@eslint eslint bot added the archived due to age label Feb 7, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.