Bad line breaking before '+', '-', '&&' etc, even when in parenthesis #735

Open
Skalman opened this Issue Nov 6, 2012 · 14 comments

Comments

Projects
None yet

Skalman commented Nov 6, 2012

function plusone(x) {
  return (x
    + 1);
}

In the function above JSHint complains that there is a Bad line breaking before '+', even though the whole return is within parenthesis, specifically to avoid ASI.

I use this style of coding because I find that it's easy to lose track of a + at the end of the line. Having it in the beginning gives me a better/quicker overview/understanding, especially when there is a really long, multi-line expression following.

Also operators which aren't subject to ASI are affected, such as && or ||. Is this considered bad style that should be avoided?

Owner

valueof commented Nov 22, 2012

I am marking this as a bug but just letting you know this won't be very high on my priority list at the moment. As for && you are right, it is a style thing.

I like to have operators at the beginning of lines, be it + or && or other. As Skalman pointed out, it is too easy to lose track if they are at the end of a line.

There should be an option to disable this, at least (similar to what already exists for comma)

+1. I'm think prefix && and || can make code more readable:

var isValid = function() {
    return !this.position && !this.employer && !this.description
                && (angular.isDefined(this.position)
                    || angular.isDefined(this.employer)
                    || angular.isDefined(this.description));
};

Agree, just ran into this. I would love a "laxlogical" to except or/and rather than disable line break checking altogether.

+1

tobek commented Jul 18, 2014

+1

I think the operator-first style is much easier to scan, especially for long multi-line conditionals, and there are no ASI gotchas in this case.

+1

What's the state here? I think also operator-first style is much easier to read.

Example

Owner

rwaldron commented Sep 5, 2014

@martensms style-related rules are being deprecated and we recommend using JSCS which provides better style validation tooling. Ping @mikesherov if you have any questions about getting started.

Contributor

mikesherov commented Sep 10, 2014

@rwaldron is this option still in the latest JSHint? I thought it was removed. If so, close this issue? If not, perhaps consider removing these rules.

@rwaldron So there's no option in jshint to deactivate that? Did you consider that this might be a break in usage? If style-related rules are deprecated, you should at least offer an option to deactivate it.

Owner

rwaldron commented Oct 31, 2014

@martensms that happened before I took over the project.

@mikesherov I can't agree with you more.

crohrer commented Dec 15, 2014

+1 for && and ||

mikesherov locked and limited conversation to collaborators Dec 16, 2014

@rwaldron rwaldron added JSHint 3 Proposal and removed Proposal labels Jan 4, 2015

Owner

rwaldron commented Jan 4, 2015

Sorry, this isn't a "proposal" as it's already been agreed to

lukeapage added this to the v3.0.0 milestone Jun 15, 2015

lukeapage added the Bug label Jun 20, 2015

@jugglinmike jugglinmike modified the milestone: v3.0.0 Jun 25, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.