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

The max after the map is removed #489

Open
kojix2 opened this issue Oct 21, 2024 · 7 comments · May be fixed by #534
Open

The max after the map is removed #489

kojix2 opened this issue Oct 21, 2024 · 7 comments · May be fixed by #534

Comments

@kojix2
Copy link

kojix2 commented Oct 21, 2024

Code:

list.map { |i| i.size }.max

Ameba auto correct

ameba --fix

The map is not replaced with max_of, but simply max is removed.

list.map(&.size)
@kojix2
Copy link
Author

kojix2 commented Oct 21, 2024

The original code when I discovered this behavior was:

max = glossary_list.map { |g| g.name.size }.max.not_nil!

@Sija
Copy link
Member

Sija commented Oct 24, 2024

Interestingly it occurs only when both Style/VerboseBlock and Performance/MinMaxAfterMap rules are enabled and trying to auto-correct the code.

@Sija
Copy link
Member

Sija commented Oct 24, 2024

@FnControlOption Could you take a look at it, please?

@FnControlOption
Copy link
Contributor

Hi @Sija, hope you are doing well. Unfortunately, I won’t have much time to look at this until around December 14

@Sija
Copy link
Member

Sija commented Jan 5, 2025

@FnControlOption Hi, I hope you're doing well. Would you have time to look at this? All the best in the New Year, btw! 🎉

@FnControlOption FnControlOption linked a pull request Jan 5, 2025 that will close this issue
@straight-shoota
Copy link
Contributor

Just throwing in an idea: I'm wondering if it would make sense to order and separate rule application by category. For example, Performance rules could have higher precedence than Style: performance issues should be adressed first, before stylistic ones.

Of course it wouldn't solve the problem in general as it cannot avoid conflicts between rules in the same category. But it would reduce the problem space and fix the particular issue at hand.

@Sija
Copy link
Member

Sija commented Jan 6, 2025

@straight-shoota That wouldn't reduce the problem space, since the corrections are totally independent of the rule category.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants