space-infix-ops: relaxed version

[madbence]

I think the space-infix-ops is too strict, the code is often more readable when spaces are used only around low precedence operators:

// readable, operator precedence is obvious
var foo = bar*baz + qux*woof;

// not so readable
var foo = bar * baz + qux * woof;

But I'm not sure how to generalize this behaviour...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[michaelficarra]

I think you should write your own rule. If it's working out well for you and you think others may want it, come back and make a more concrete proposal that includes the implementation.

[nzakas]

It's hard to understand your expectations of a change to this rule.​ The
examples you cite seem to indicate that order of operations is the
determining factor as to which operators should be spaced (I'm not sure
that's your intent, that's just how it looks). Since readability is highly
personal, my approach to handling that situation would be to place
parentheses around the multiplication operations rather than eliminating
the space around the operator, for example.

In order to even consider making a change, we'd need a concrete proposal
explaining the details of the change.

[madbence]

Sure, I'll try to clarify how this rule should behave (and I'll write a pr). @michaelficarra I think this is definitely an extension for space-infix-ops, and not a new rule.

[nzakas]

Please write the description before doing a PR. I'm still not sure we should change the rule, so I wouldn't want you spending time coding unless we were sure this was something to consider.

[jonvuri]

Are there any examples of style guides that prescribe this? I've never seen this style implemented anywhere before. It seems like kind of an odd style, too - I'm sure it works for you, but it seems like it would make the squashed parts of the expressions a little harder to read, and it wouldn't scale very well to anything more complex than a couple successive infix operations.

[madbence]

@nzakas I don't want to change the rule, I just want to add a new configuration option to it (backward compatible change). I'll work on the spec during the weekend.

[nzakas]

Adding a new option is a change. :) That was my point.​

[Skalman]

I'll give it a shot, as I use a similar unspoken rule. I only apply it to mathematical operators, since those are all single character operators frequently used with numbers and short variables.

Here's a description of my rule:

If neither the LHS nor the RHS is surrounded by parenthesis, operators *, / and % don't have to have a surrounding space.

// OK
1*2 + 3/4 - 5%6
(1*2 + 3%4) / (5 + 6)
(1 * 2 + 3 % 4) / (5 + 6) // They *may* have surrounding spaces.
(1 * 2 + 3%4) / (5 + 6) // They may even have inconsistent surrounding spaces.

// Not OK
1*2+3 // The + operator still must have surrounding spaces.
1/(2 + 3) // Space is required, because the RHS has surrounding parenthesis.

It's possible that it would make sense to have something similar for bitwise operators, but I don't use them so I wouldn't know how it should work.

---

Edit: A simpler rule would be to ignore the parentheses. The rule then simply becomes:

Operators *, / and % don't have to have a surrounding space.

[puzrin]

I don't have style guide, but can confirm, that had "unnecessary" warning in math equations. The most typical is a*b + c*d + e*f on matrix calc.

Also, i'm not sure it's worth to require space on some array patterns:

a = b[i-1]; // now requires a = b[i - 1]

[gyandeeps]

Any update on how we are managing this as this issue has been opened for a long time now.

[nzakas]

Let's just close it - it's been open almost a year without any progress.