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

Jump to bottom

New Cop Idea: Explicit operator precedence #7849

Closed
tejasbubane opened this issue Apr 4, 2020 · 3 comments
Closed

New Cop Idea: Explicit operator precedence #7849

tejasbubane opened this issue Apr 4, 2020 · 3 comments
Labels
feature request good first issue Easy task, suitable for newcomers to the project

Comments

@tejasbubane
Copy link
Contributor

Is your feature request related to a problem? Please describe.

This is a request for new cop based on @bbatsov's comment here.

Describe the solution you'd like

The cop should check for explicit parens when operators with varying precedence are used in a statement.

# bad
a && b || c
10 + 20 * 3

# good
(a && b) || c
10 + (20 * 3)

Describe alternatives you've considered

NA

Additional context

We need to decide if the cop should consider all operators or only commonly used ones.
@bbatsov
Copy link
Collaborator

bbatsov commented Apr 4, 2020

Well, I have to say I love the idea! 😉

@bbatsov bbatsov added feature request good first issue Easy task, suitable for newcomers to the project labels Apr 4, 2020
rahul404 pushed a commit to rahul404/rubocop that referenced this issue Apr 26, 2020
[Fix rubocop#7849] Add ExplicitOperatorPrecedence cop
ee2f8dc 
Fixes rubocop#7849

This cop checks if binary operators of different precedents are
used without explicit use of parenthesis.

```ruby
a && b || c
a * b + c
a ** b * c / d % e + f - g << h >> i & j | k ^ l

(a && b) || c
(a * b) + c
(((((a**b) * c / d % e) + f - g) << h >> i) & j) | k ^ l
```
@rahul404 rahul404 mentioned this issue Apr 26, 2020
Closed
@rahul404
Copy link

Hi @bbatsov, I have made a PR for this feature. There is one issue I can fix in it.
The test case to fix a ** b * c / d % e + f - g << h >> i & j | k ^ l fails. Somehow the cop exercises the correction method only once.

@mvz
Copy link
Contributor

mvz commented May 12, 2020

It would be nice to have this depend somehow on the complexity of the expression. But then again, I think a ** b * c / d % e + f - g << h >> i & j | k ^ l would be equally hard to comprehend with parentheses.

dvandersluis added a commit to dvandersluis/rubocop that referenced this issue Aug 26, 2021
@dvandersluis
[Fix rubocop#7849] Add new Lint/AmbiguousOperatorPrecedence cop.
f0e1373
@dvandersluis dvandersluis mentioned this issue Aug 26, 2021
Merged
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature request good first issue Easy task, suitable for newcomers to the project
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Fix #7849] Add ExplicitOperatorPrecedence cop rahul404/rubocop
4 participants
@mvz @bbatsov @tejasbubane @rahul404