Open adamchainz opened 1 year ago
Hi @adamchainz - that's a great point - I guess a ~ 80 char limit might well make sense here?
If the 80 chars includes the if var :=
, then yeah something like that would make sense.
The same 80 chars condition should apply to refactorings/assign-if-exp
, since most of the time in my code the proposed refactoring would exceeds our/blacks line length limit.
Oh yeah, I disabled assign-if-exp
altogether, I don't like return x if y else z
generally, but the long lines did push me.
Expression complexity is worth considering. For example:
return data.get('monthly', {}).get(date, None) if data else None
This is <80 chars, even when indented, but to my eye the number of pieces in the first expression pushes the if data else None
to be ignored too easily. A limit of, say, 5 pieces (names, operators) in expressions would stop this happening.
Checklist
Description
Sourcery currently seems to do this with even long expressions:
For example, with Django ORM calls that may chain several methods in order to create the right query. Combining all that onto one line is less readable IMO.
I suggest some kind of complexity limit on expressions that get walrus-ed by this rule.
Debug Information
IDE Version: n/a
Sourcery Version: 0.12.7
Operating system and Version: macOS