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

Require block comments to be balanced #572

Closed
feross opened this issue Jul 22, 2016 · 4 comments
Closed

Require block comments to be balanced #572

feross opened this issue Jul 22, 2016 · 4 comments

Comments

@feross
Copy link
Member

feross commented Jul 22, 2016

http://eslint.org/docs/rules/spaced-comment

This rule (which is already enabled in standard) has a new option to enforce "balanced" spacing in block comments.

For example, this would be an error:

/* This is a block comment*/

It would be need to be rewritten like this:

/* This is a block comment */

As part of this change, I propose that we remove the exceptions that allow the keywords "global", "global", "eslint", and "eslint-disable" to be used without a space:

/*global myVar */

It's odd to enforce a space at the end while making it optional at the beginning for these keywords. With these exceptions removed, this is how these comments would need to be written:

/* global myVar */

Eslint handles space or no-space versions of these directives without issue.

The number of affected repos is moderate (2%):

1..422
# tests 422
# pass  412
# fail  10

Thoughts?

feross added a commit to standard/eslint-config-standard that referenced this issue Jul 23, 2016
feross added a commit to standard/eslint-config-standard that referenced this issue Jul 23, 2016
@dcousens
Copy link
Member

LGTM

@feross
Copy link
Member Author

feross commented Jul 25, 2016

This will be included in standard v8

@Jessidhia
Copy link

Jessidhia commented Jul 25, 2016

I kinda like being able to write eslint directives in a "style-violating" way (and wish I could do it with more of them, like //eslint-disable-line) because, if the directive has a typo, it will be flagged by the linter instead of just being ignored. OTOH, if you have a directive, it's because it's disabling or configuring specific rules, and if the directive was being ignored, you'd be getting warnings for the things it tries to fix...

@feross
Copy link
Member Author

feross commented Jul 25, 2016

@Kovensky Interesting point. Your last point is correct. If the rule isn't getting picked up (due to a typo) then you'll get a warning because the rule you were trying to disable wasn't actually disabled.

I think this rule change is a good move since there were 2 ways to do something, and now there will be only one.

@lock lock bot locked as resolved and limited conversation to collaborators May 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

3 participants