You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
Private functions having too many arguments are not as much of a problem as exported ones. They should not be judged too severely.
Describe the solution you'd like
I would add a parameter like…
non_exported_max_arity :: pos_integer()
…with a very very large default value (e.g. 20)
Describe alternatives you've considered
An alternative would be to just ignore non-exported functions or have a flag like apply_to :: exported | non_exported | both that defaults to exported. But I think my proposal above is more flexible.
The text was updated successfully, but these errors were encountered:
I'd simply ignore the private functions (but yeah, going with a super-high default might not hurt, either). Once they're exposed the rule kicks in and changes might be in order.
I don't know which one is better, but from the name of the issue, I assume that you want to add the ignoring version first based on @elbrujohalcon's alternative idea.
Is your feature request related to a problem? Please describe
Private functions having too many arguments are not as much of a problem as exported ones. They should not be judged too severely.
Describe the solution you'd like
I would add a parameter like…
non_exported_max_arity :: pos_integer()
…with a very very large default value (e.g.
20
)Describe alternatives you've considered
An alternative would be to just ignore non-exported functions or have a flag like
apply_to :: exported | non_exported | both
that defaults toexported
. But I think my proposal above is more flexible.The text was updated successfully, but these errors were encountered: