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

Add option to Metrics/BlockNesting to actually check blocks #3670

Merged

Conversation

georgyangelov
Copy link
Contributor

Currently, the Metrics/BlockNesting cop does not consider blocks to be a nesting level. There are some cases where this is desirable.

This PR makes the block nesting cop configurable. The option is called ConsideredBlocks and can have a value of none, multiline and all.

none is the default which does not change the cop's current behavior. multiline considers multiline blocks as a nesting level and all counts both single-line and multiline blocks.

While implementing this, I saw that the two mixins ConfigurableMax and ConfigurableEnforcedStyle cannot be used both in a cop. They were both defining a parameter_name method and one was overriding the other. I have changed the name of these methods to style_parameter_name and max_parameter_name.

Please verify that my approach in the block detection is correct since this is my first time editing a cop and I'm not entirely familiar with Node's interface.

P.S. I changed my GitHub username and edited that in the contributor list.

@georgyangelov georgyangelov force-pushed the block-nesting-block-check-option branch from 8ab78d7 to 4b7d379 Compare October 23, 2016 16:38
@bbatsov
Copy link
Collaborator

bbatsov commented Oct 30, 2016

I took a cursory glance at the code and I wonder why are single-line and multi-line blocks treated separately. After all blocks are blocks, despite of their length...

def message(max)
"Avoid more than #{max} levels of block nesting."
end

def style_parameter_name
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems odd to be using the style-related code for something that's not the cop's enforced style, but an additional config option. @jonas054 Thoughts?

@georgyangelov
Copy link
Contributor Author

@bbatsov, I agree. However, there may be multiple points of view regarding what is considered a nesting level. One might consider only the indented code as a nesting level (which does not include inline blocks). This is not my view on the point, but I think this will allow for more customizability and may ease the transition. If you think the distinction is not needed, I will leave it out.

@bbatsov
Copy link
Collaborator

bbatsov commented Dec 13, 2016

Let's not overdo this. I'd suggest treating all blocks in the same manner for starters and see what feedback this change is going to get when merged.

@bbatsov
Copy link
Collaborator

bbatsov commented Dec 20, 2016

ping @georgyangelov :-)

These mixins both defined the `parameter_name` method which was being
overriden by the other mixin.

These two were renamed to `style_parameter_name` and `max_parameter_name`.
@georgyangelov
Copy link
Contributor Author

@bbatsov, sorry for the delay. I've updated the option and rebased the branch on the latest master.

I've left the parameter_name change in here because it seemed good to have. Let me know if you want to remove it from the PR.

@bbatsov bbatsov merged commit 144158f into rubocop:master Dec 21, 2016
@bbatsov
Copy link
Collaborator

bbatsov commented Dec 21, 2016

Thanks! 👍

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

Successfully merging this pull request may close these issues.

2 participants