Rubocop: SpaceAroundOperators should be allowed to have spaces around **

[ptarjan]

I'd like to allow spaces around all operators, including **.

Expected behavior

This is allowed

capped_size 200 * (10 ** 9) # i.e. 200GB

Actual behavior

a.rb|1 col 23 warning| Style/SpaceAroundOperators: Space around operator `**` detected. [ruby/rubocop]

Steps to reproduce the problem

Put that source in a file

RuboCop version

$  rubocop -V
0.38.0 (using Parser 2.3.0.6, running on ruby 2.1.2 x86_64-darwin15.0)

[bbatsov]

Guess you haven't read this section of the community style guide. :-)

This is not a bug - it's a feature. Maybe we should make it configurable, but it's definitely not something I consider important.

[ptarjan]

@bbatsov I read it, I just didn't see the reasoning behind it. Please teach me why that operator is special. :)

I asked around our company and other engineers were equally baffled as I was. Maybe with 3 * 4**5 it nicely shows precedence, but when there are parens around it, 3 * (4**5) feels out of place.

[bbatsov]

Think about the result of 2**3**4. The op's applied from right to left, unlike all other arithmetic operators. The lack of spaces also makes it a bit closer to its standard superscript notation (tightly grouped with the base number in question). This was the reasoning there (at least the part I remember).

[agrimm]

@bbatsov that comment has been markdowned to 2(bold)3(unbold)4.

[bbatsov]

@bbatsov And that attitude is exactly why Rubocop is so frustrating to work with. You're not trying to make a helpful tool for developers to reduce errors in their code, you're trying to enforce your way of thinking and your preferred style.

Do you have any idea how much of my time I've wasted adding functionality I don't really need or care about? Before jumping to conclusions you should think long and hard about the efforts required to maintain a project with the scale and complexity of RuboCop. You can't seriously expect me to implement everyone's requests... That's an open-source project if you want some functionality in, the recipe for success is easy - please contribute it! :-)

[bbatsov]

No, and I don't care. You're maintaining a project and this:

Why should I care then?

I'm not jumping to the conclusions you seem to believe. I'm jumping to the conclusion that you're just slapping down someone elses opinions and desire for a feature with no respect what-so-ever for the fact that they have a different viewpoint to yours - that's what I think is poor and I think that attitude shines through in the pain in the arse it is to deal with Rubocop day to day.

I'm not forcing nobody to use RuboCop. You're welcome to use some other tool if you find RuboCop a painful experience.

No one asked you to implement it personally, but I can't see myself spending a minute writing code to improve a project run with this attitude to perfectly reasonable requests. Your response at best leaves me uncertain whether such a patch would even be accepted in this case.

I don't see anything off-putting in my comment. I pointed out why this behaves as it does and I said this might be made configurable. Anyways, PRs welcome. That's all I have to say about this.

[backus]

I hate seeing issues turn negative like this so I'll just chime in and say I love rubocop and I think it is incredibly flexible. I really appreciate the amount of work @bbatsov has to put in just to review all of the issues and PRs that rubocop gets every day.

[Drenmi]

I hate seeing issues turn negative like this so I'll just chime in and say I love rubocop and I think it is incredibly flexible. I really appreciate the amount of work @bbatsov has to put in just to review all of the issues and PRs that rubocop gets every day.

If it weren't for the Ruby Style Guide, I would be thoroughly lost, and we have reaped enormous benefits from the programmatic enforcement of RuboCop at work. All thanks to the free work and hard effort @bbatsov and others put in. 😊

[bbatsov]

Thanks for the kind words, guys! At any rate - I'd happily accept a PR addressing this ticket.

[sparr]

I am in favor of an option to control this, or a separate cop. If I can wrap my head around the layers of abstraction present in the operator-handling cops then I'll try to PR this.

[mikegee]

It looks like the cop explicitly excludes **. This should be simple to change.

Someone that wants to pursue this should probably open an issue at https://github.com/bbatsov/ruby-style-guide first and see if there is sufficient consensus changing the recommendation there.

[bbatsov]

I'm closing this ticket due to no recent activity. Feel free to re-open it if you ever come back to it.