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

More eslint #1536

Merged
merged 4 commits into from Apr 13, 2015
Merged

More eslint #1536

merged 4 commits into from Apr 13, 2015

Conversation

froatsnook
Copy link
Contributor

I updated eslint to 0.18.0 and added a couple rules for style consistency.

    // Use if () { }
    //       ^ space
    "space-after-keywords": [2, "always"],

There were only a few instances of if() and else{ in the code, so this was clear.

    // Use if () { }
    //          ^ space
    "space-before-blocks": [2, "always"],

There were only a few instances of if (){ in the code, so this was also clear.

    // Use function test() { }
    //                 ^^ no space
    "space-before-function-paren": [2, "never"]

This one was harder. There were tons of function ()s and function name ()s in the code, including function Request (). But there were way more function()s and function name()s. Introducing with "always" created 739 errors, vs "never" creating 245.

One additional change (1ffc50d): eslint complained about an empty block statement, so I added the comment // empty to explicitly mark it as empty.

@simov
Copy link
Member

simov commented Apr 10, 2015

That's great, I'm only not too sure about the space-before-function-paren rule.

If you run (without the tests)

node node_modules/.bin/eslint lib/ *.js

with "space-before-function-paren": [2, "never"] you get 99 warnings

with "space-before-function-paren": [2, "aways"] you get 41 warnings

So it turns out that there are more occurrences using space, of course without the tests, but they were largely refactored by one person at some point.

So I'm for keeping the things as they are for now regarding this rule.

@froatsnook
Copy link
Contributor Author

So I'm for keeping the things as they are for now regarding this rule.

Do you mean set it to always? Or leave the rule off?

@simov
Copy link
Member

simov commented Apr 10, 2015

I was thinking about leaving it off, which is not perfect either, and it will be a matter of personal preference whichever we choose.

@froatsnook
Copy link
Contributor Author

I would say we should just pick something. This is a much less polarizing style issue than some of the other rules.

@simov
Copy link
Member

simov commented Apr 10, 2015

I agree that we should pick one, but which one exactly? For example I'm using spaces always, so it would be perfectly fine for me to have all places changed to using spaces. Just by looking at the diff I can say that other developers have the same preference too.

On the other hand saying that you should always use space might not be appealing to everyone, so that's why my suggestion was to leave that rule off for now.

But lets try to make a quick pool.

@mikeal @FredKSchott @nylen pick either 1) or 2)

function()
function func(param)
function ()
function func (param)

@simov
Copy link
Member

simov commented Apr 13, 2015

Ok, so I'm sticking to my initial decision about this one to keep the space-before-function-paren as it was up until now. I don't mind any of the two spacing schemes, but I'm not ok with forcing everyone to use either one.

So, @froatsnook can you revert only this froatsnook@22870c7 commit?

@froatsnook
Copy link
Contributor Author

Sure, will do.

@froatsnook
Copy link
Contributor Author

OK, reverted.

@simov
Copy link
Member

simov commented Apr 13, 2015

Thanks 👍

simov added a commit that referenced this pull request Apr 13, 2015
@simov simov merged commit 3afa3fa into request:master Apr 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants