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.

Sign up for GitHub

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

Jump to bottom

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
Labels
enhancement

Comments

@feross
Copy link
Member

feross commented Jul 22, 2016 •
edited
Loading

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
Enforce balanced block comments
dab976e 
See standard/standard#572
@feross feross mentioned this issue Jul 23, 2016
Merged
feross added a commit to standard/eslint-config-standard that referenced this issue Jul 23, 2016
@feross
Enforce balanced block comments
4e29de1 
See standard/standard#572
@dcousens
Copy link
Member

LGTM

@feross
Copy link
Member Author

feross commented Jul 25, 2016

This will be included in standard v8

@feross feross closed this as completed Jul 25, 2016
@feross feross mentioned this issue Jul 25, 2016
Closed
16 tasks
@Jessidhia
Copy link

Jessidhia commented Jul 25, 2016 •
edited
Loading

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.

@saadq saadq mentioned this issue Aug 25, 2016
Merged
@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.
Assignees
No one assigned
Labels
enhancement
Projects
The Standard Project
Archived in project
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Jessidhia @feross @dcousens