-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
Action Order Cop #547
Action Order Cop #547
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! This is missing a few required things, including tests, a changelog entry, adding a require to https://github.com/rubocop/rubocop-rails/blob/master/lib/rubocop/cop/rails_cops.rb, adding an entry for this cop to https://github.com/rubocop/rubocop-rails/blob/master/config/default.yml.
cfce285
to
2103106
Compare
Thanks for making the changes I requested. Looks good at this point, but still requires tests in order to be merged. |
The missing elements I requested are there now.
Thanks for all your help guys. I implemented autocorrection, but I feel like I have to try it on our codebase before I feel I can trust it. Also, I don't know how to mark it as a safe/unsafe correction (-a vs -A) or which it should be marked as. |
The only way I can think of that would be unsafe is if someone had accidentally defined the same method twice in a controller, so that only the later one was in use. Then re-ordering might change the behaviour. |
Heh yeah, so it comes down to the significance of -A vs. -a I guess -a should never ever have any opportunity to go wrong, so we have to stick to -A because of this strange edgecase? |
One approach that could make it safe would be to have the cop fail if multiple identical action names are detected. |
(normally |
Yeah. I could complicate things by trying to check for duplicates here, and disable auto correction in that case? Though it seems quite pedantic, and could lead to less clear code. |
I'd suggest aiming for a first release without safe-correction, and then safe-correction can be addressed in a follow-up. |
Thank you for considering the corner case. However, whether it is an unsafe auto-correction is not determined by progress of implementation. This is determined by cop design. I think this cop can be safely designed due to changes to layout. So, if auto-correction is implemented, safe auto-correction ( Before auto-correctiondef edit
end
def index # first
end
def show
end
def index # second
end After auto-correctiondef index # first
end
def index # second
end
def show
end
def edit
end Both should be remain for duplicate defined methods. So, I think it can make a design that compatible behavior. Can you add the above test case and for the implementation? |
It's done! And thanks, we avoided an infinite loop by testing this corner case ( |
@pirj I feel like this one is good to go now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall 👍
I'd love to see a spec that shows how it behaves:
- when non-resourceful methods are present in the controller
- when private/protected methods are present
I personally don't mind turning this cop on by default (set it to pending
now, and we'll flip it to enabled
on a major release) - that's the reason the pending
status was introduced, see https://docs.rubocop.org/rubocop/1.21/versioning.html#pending-cops
However, if you'd like to do so - please run the cop against real-world-rails to find out if there are any false positives or errors.
It's a good practice anyway to run newly introduced cops on a number of projects. We do this in rubocop-rspec
at least.
Do you mean spec/rubocop/cop/rails/action_order_spec.rb:70
I just looked into it. I guess we'll have to only run this cop on public methods. Unfortunately, I see no simple way of detecting if a method is public or not with rubocop? The only way of implementing this I can think of is to manually read through the class, detecting any access_modifiers ( |
I'll look into it |
Makes sense.
There seems to be this and this, but frankly I never used any of them. # 1.rb
class UserController < ApplicationController
def commit; end
def show; end
private
def index; end
end # 2.rb
class UserController < ApplicationController
def commit; end
def show; end
private def index; end
end
For |
Please accept my apologies, missed that example completely 🙈 👍 |
This PR for merge is ready AFAIK. |
This looks good to me. Can you use the new changelog entry format instead of CHANGELOG.md and squash your commits into one? |
@mollerhoj ping :-) |
@mollerhoj ping |
a649a08
to
f8cb390
Compare
45e9497
to
e4a65f3
Compare
e4a65f3
to
effdb0a
Compare
Thanks! |
Please excuse any obvious mistakes, this is my first cop.
Fix #540