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

ci(ruff): Enforce the default C901 complexity #3531

Merged
merged 5 commits into from
Aug 10, 2024

Conversation

dangotbanned
Copy link
Member

References

Previously was set at 18, the default is 10.
As the rule was not in [tool.ruff.lint.select], the setting was never used.
Setting such a high limit hides opportunities to simplify large, complex functions.

Many cases were resolved/improved in #3431.
There were 2 I fixed in this PR as they were quite simple changes.
The remainder use the # noqa: C901 comment to serve as a TODO.

https://docs.astral.sh/ruff/settings/#lint_mccabe_max-complexity
Previously 18, the default is 10.

As this rule was not in `[tool.ruff.lint.select]`, it was not used.

Setting such a high limit hides opportunities to simplify large, complex functions.
Many cases were resolved/improved in vega#3431.
The remainder can use the *# noqa: C901* comment to serve as a TODO
These are mostly too complex to handle in this PR, it would be a very difficult review
Ideally tests would be split up enough to not fail this lint, but not a major issue
@@ -218,7 +218,7 @@ def __init__(
)

@traitlets.observe("chart")
def _on_change_chart(self, change):
def _on_change_chart(self, change): # noqa: C901
Copy link
Member Author

Choose a reason for hiding this comment

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

I think this was the highest, at around 20

@@ -3876,7 +3876,8 @@ def _check_if_valid_subspec(
raise ValueError(err.format(attr, classname))


def _check_if_can_be_layered(spec: LayerType | dict[str, Any]) -> None:
# C901 fixed in https://github.com/vega/altair/pull/3520
def _check_if_can_be_layered(spec: LayerType | dict[str, Any]) -> None: # noqa: C901
Copy link
Member Author

Choose a reason for hiding this comment

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

See the resolution for this in #3520

@jonmmease
Copy link
Contributor

Thanks for working through these rules @dangotbanned!

I'll defer to others, but I don't personally find C901 all that helpful. We should of course use functions and classes to minimize duplication of logic, but for an inherently complex function that doesn't contain logic that's useful elsewhere, I don't personally get much benefit from it being broken down into smaller functions. And I suppose this is reflected in my coding style 😄

@dangotbanned
Copy link
Member Author

dangotbanned commented Aug 10, 2024

Thanks for working through these rules @dangotbanned!

I'll defer to others, but I don't personally find C901 all that helpful. We should of course use functions and classes to minimize duplication of logic, but for an inherently complex function that doesn't contain logic that's useful elsewhere, I don't personally get much benefit from it being broken down into smaller functions. And I suppose this is reflected in my coding style 😄

Totally valid point @jonmmease! Appreciate your thoughts.

Choosing to use C901 (or any rule really) is ultimately opt-in per "violation".
I shouldn't have phrased it in the description as every case needing to be "fixed".

Personally, the benefit to me when writing new code is that the warning prompts me to consider if there is an alternative way to write the function:

function is too complex (15 > 10)

If there isn't, or if it is time sensitive (or I disagree with the warning) - add a # noqa: C901 and move on.
The important part is the moment of pause the rule introduces, which for me usually leads to thinking more critically about my own code

@jonmmease
Copy link
Contributor

Yeah, it's easy to disable when needed. So no objection, and the small changes you needed to make to pass the check all look positive to me.

@jonmmease jonmmease self-requested a review August 10, 2024 16:33
Copy link
Contributor

@jonmmease jonmmease left a comment

Choose a reason for hiding this comment

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

Looks good. Feel free to merge when you're ready!

@dangotbanned
Copy link
Member Author

Looks good. Feel free to merge when you're ready!

Thanks @jonmmease!

FYI if at any time you find it frustrating to add a lot of ignore comments (for a single file), you can always add to our tool.ruff.lint.per-file-ignores table instead

https://docs.astral.sh/ruff/settings/#lint_per-file-ignores

@dangotbanned dangotbanned merged commit e402b3c into vega:main Aug 10, 2024
13 checks passed
@dangotbanned dangotbanned deleted the remove-high-max-complexity branch August 10, 2024 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants