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

Allows for empty if blocks #6993

Merged
merged 3 commits into from Apr 30, 2019
Merged

Allows for empty if blocks #6993

merged 3 commits into from Apr 30, 2019

Conversation

RicardoTrindade
Copy link
Contributor

@RicardoTrindade RicardoTrindade commented Apr 29, 2019

On version 0.68, if you an empty if block, rubocop throws an error. This PR aims to fix this error, allowing for empty blocks with comments. Would like to get your opinion on this, do you think there's a need for a new cop that does not allow for empty if blocks, or if this fix is enough.

 NoMethodError:
       undefined method `type' for nil:NilClass

Error occured with:
0.68.0 (using Parser 2.6.3.0, running on ruby 2.3.7 x86_64-linux)

Before submitting the PR make sure the following are checked:

  • Wrote good commit messages.
  • Commit message starts with [Fix #issue-number] (if the related issue exists).
  • Feature branch is up-to-date with master (if not - rebase it).
  • Squashed related commits together.
  • Added tests.
  • Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
  • The PR relates to only one subject with a clear title
    and description in grammatically correct, complete sentences.
  • Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

@@ -151,7 +151,12 @@ def extract_parts_from_if(node)

checked_variable, matching_receiver, method =
extract_common_parts(receiver, variable)
matching_receiver = nil if LOGIC_JUMP_KEYWORDS.include?(receiver.type)

Copy link
Member

Choose a reason for hiding this comment

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

I would go first by renaming modifier_if_safe_navigation_candidate? to just modifier_if_safe_navigation_candidate as it doesn't return a boolean value. Next, if the receiver is returned, it is a Node for sure, so no need for the second check (receiver.type). So it may become matching_receiver = nil if receiver.nil? || LOGIC_JUMP_KEYWORDS.include?(receiver.type). Which isLOGIC_JUMP_KEYWORDS a bit long, so it may be extracted in a method

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright, thanks! Made those changes, just not sure about the method extracted being called safeguarded?, maybe not the best of names.

@@ -250,6 +252,10 @@ def add_safe_nav_to_all_methods_in_chain(corrector,
break if ancestor == method_chain
end
end

def safeguarded?(receiver)
receiver.nil? || LOGIC_JUMP_KEYWORDS.include?(receiver.type)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Won't this be slightly better as receiver && LOGIC_JUMP_KEYWORDS.include?(receiver.type)? I'm not sure this method is needed, though, as I think it's name is confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, removed that method and applied your suggestion.

@bbatsov bbatsov merged commit 853de37 into rubocop:master Apr 30, 2019
@bbatsov
Copy link
Collaborator

bbatsov commented Apr 30, 2019

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.

None yet

3 participants