-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Use flake8 simplify #4798
Use flake8 simplify #4798
Conversation
Yes, should be fixed :) |
The initial work looks good, and the list of lints at the attached repo also look very helpful for ensuring readable code. As long as the lint isn't too aggressive and the error messages are helpful (don't want to overwhelm new contributors), implementing this looks good to me. |
48d889e
to
3ce8ab4
Compare
I fixed all violations except for If the violation is in a simple
In order to handle the error first, I have to add:
which could be simplified to
But what happens if an additional case has to be added (another In my opinion, @finswimmer, @neersighted: What do you think? |
I do think that the general structure proposed by SIM106 is more readable, but I agree that long-term maintainability may be compromised if the pattern is not easily internalized. I'm fine with disabling the check for now, and revisiting later, personally. All the other changes on this PR look like pretty unambiguous wins for readability and maintainability. |
* Fix SIM102: Use a single if-statement instead of nested if-statements * Fix SIM105: Use 'contextlib.suppress(...)' instead of try-except-pass * Fix SIM110: Use 'return any(...)' * Fix SIM113: Use enumerate instead of manually incrementing a counter * Fix SIM114: Combine conditions via a logical or to prevent duplicating code * Fix SIM211: Use 'not a' instead of 'False if a else True' * Fix SIM300: Use 'age == 42' instead of '42 == age' (Yoda-conditions) * Fix SIM119: Use dataclasses for data containers * Ignore "SIM106: Handle error-cases first" for now
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Pull Request Check List
Relates-to: #4776
I plan to have one commit per violation code, so you can easily check if you like all of them.
Before I tackle SIM300 Yoda conditions (which is by far the most frequent violation): You also think that this should be fixed, don't you? (Just want to make sure because I know some people who like Yoda conditions). Hopefully, most of these conditions can be replaced with some sort of regex, I still have to come up with. 😀