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

[POC] all: fix deepsource checks #2016

Closed
wants to merge 19 commits into from
Closed

Conversation

RhinosF1
Copy link
Contributor

@RhinosF1 RhinosF1 commented Jan 15, 2021

Description

Cleans up a bunch of possible style issues per https://deepsource.io/gh/RhinosF1/sopel/issues/?category=recommended

This is a proof of concept but if you like the feedback then I can go further or it could be configured on your end too.

Checklist

  • I have read CONTRIBUTING.md
  • I can and do license this contribution under the EFLv2
  • No issues are reported by make qa (runs make quality and make test)
  • I have tested the functionality of the things this change touches

deepsourcebot and others added 19 commits January 15, 2021 22:25
Refactor unnecessary `else` / `elif` when `if` block has a `raise` statement
Refactor unnecessary `else` / `elif` when `if` block has a `return` statement
Refactor unnecessary `else` / `elif` when `if` block has a `break` statement
Replace ternary syntax with if expression
Remove methods with unnecessary super delegation.
Refactor the comparison involving `not`
Remove unnecessary lambda expression
Use literal syntax instead of function calls to create data structure
@Exirel
Copy link
Contributor

Exirel commented Nov 13, 2021

Almost a year now, and I don't think we gave it a proper review. Probably because, as you may have guest, I'm not a huge fan of adding yet another tools with yet another opinions on code style.

I think it's fair to say we can close this. What do you say @dgw ?

Copy link
Member

@dgw dgw left a comment

Choose a reason for hiding this comment

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

I'm not a huge fan of adding yet another tools with yet another opinions on code style.

What do you say @dgw ?

I say what's below in the line notes. tl;dr: This tool does have some useful rules, but I can only see documentation on ignoring issues in specific lines. One reason I think flake8 has been our preference for code style is that it lets you globally decide that you don't care about a certain style rule, and in many cases there are multiple rules to choose from (e.g. putting binary operators at the beginning or end of a line).

If there's really no way to customize the style rules applied by DeepSource, then the way forward is to look for flake8 plugins that enforce the DeepSource rules I/we do like and add those (to the wishlist in #1765, probably, so they can be implemented at an opportune moment).

else:
channel = self._trigger.sender
channel = self._trigger.sender
Copy link
Member

Choose a reason for hiding this comment

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

This kind of thing is good.

self.privileges = dict()
self.privileges = {}
Copy link
Member

Choose a reason for hiding this comment

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

I don't mind enforcing this kind of style.

Comment on lines 685 to 688
if '*' in disabled_plugins:
return
elif rule.get_plugin_name() in disabled_plugins:
if rule.get_plugin_name() in disabled_plugins:
return
Copy link
Member

Choose a reason for hiding this comment

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

This, on the other hand, is silly. If the tool isn't smart enough to recommend merging the two conditions into one (as below), it shouldn't flag anything. Just using elif shouldn't be a style error, and there are numerous places in this PR where it's changed to plain if for no reason.

if (
    '*' in disabled_plugins
    or rule.get_plugin_name() in disabled_plugins
):
    return

else:
return os.path.dirname(self.filename)
return os.path.dirname(self.filename)
Copy link
Member

Choose a reason for hiding this comment

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

But this kind of thing is also good.

Comment on lines -279 to +278
not current_name == new_name):
current_name != new_name):
Copy link
Member

Choose a reason for hiding this comment

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

This is good, too.

@dgw dgw added Declined Requests that will not be implemented for technical or project direction reasons Housekeeping Code cleanup, removal of deprecated stuff, etc. labels Jan 9, 2022
@dgw dgw closed this Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Declined Requests that will not be implemented for technical or project direction reasons Housekeeping Code cleanup, removal of deprecated stuff, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants