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
Note the increased nesting, and the distance between switch(x and the x value b = {.
It would be good to come up with a rule to weaken if_switch_linter() to not apply to cases where the branches are "overly complicated". The trouble is coming up with a good rule for what that means (e.g. cyclocomp_linter() only cares about branching, not the number of expressions).
One simple option is to just count the number of "child expressions" in each branch, and not lint if, say max(expressions) > complexity where complexity= is an argument set by the user, perhaps with a sensible default like 3L.
The text was updated successfully, but these errors were encountered:
I think best next step is to pull some "real" examples. not clear to me whether it's strictly LoC or code complexity that's the source of the issue here. Could be both, and we offer two parameters.
I could potentially have a single function call in a given branch but many LoC just because the function has many parameters (think ggplot2::theme()) which are formatted to be one per line for readability.
still the distance between the conditions seems important. with switch(x, ....) we might lose mental context that x is what's switched on, with if/else x is reminded every condition.
so why not two parameters, one for LoC and one for # expressions?
if_switch_linter()
is too strict -- in some cases,usingswitch()
is actually quite awkward.Would become
Note the increased nesting, and the distance between
switch(x
and thex
valueb = {
.It would be good to come up with a rule to weaken
if_switch_linter()
to not apply to cases where the branches are "overly complicated". The trouble is coming up with a good rule for what that means (e.g.cyclocomp_linter()
only cares about branching, not the number of expressions).One simple option is to just count the number of "child expressions" in each branch, and not lint if, say
max(expressions) > complexity
wherecomplexity=
is an argument set by the user, perhaps with a sensible default like3L
.The text was updated successfully, but these errors were encountered: