Skip to content

New nested_pipe_linter #2301

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

Merged
merged 10 commits into from
Nov 20, 2023
Merged

New nested_pipe_linter #2301

merged 10 commits into from
Nov 20, 2023

Conversation

MichaelChirico
Copy link
Collaborator

Part of #884

No hits on {lintr}

@codecov-commenter
Copy link

codecov-commenter commented Nov 17, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ff1dc21) 99.38% compared to head (d1dca49) 99.39%.

❗ Current head d1dca49 differs from pull request most recent head b462119. Consider uploading reports for the commit b462119 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2301   +/-   ##
=======================================
  Coverage   99.38%   99.39%           
=======================================
  Files         119      120    +1     
  Lines        5392     5412   +20     
=======================================
+ Hits         5359     5379   +20     
  Misses         33       33           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@AshesITR
Copy link
Collaborator

AshesITR commented Nov 18, 2023

This one I would carve out an exception at least for select(). But feel free to ignore that.

Tests for metadata are missing.

@MichaelChirico
Copy link
Collaborator Author

This one I would carve out an exception at least for select(). But feel free to ignore that.

Tests for metadata are missing.

Equally common I think is DF1 |> inner_join(DF2 |> filter(...)).

For select() the issue becomes cases like:

DF1 |>
  inner_join(
    DF2 |>
      select(
        a, b, c, d,
        e, f, g, h, i
      )
  )

This was part of my motivation for the whole linter to begin with -- it becomes quite hard to tell at a glance how |> will parse (is it part of the DF1 |> pipeline... no... where does that nested pipeline begin exactly?).

For select(), the advantage of assigning an intermediate variable is not as clear as for filter(). so I see why that's a pretty good default.

But maybe we should add logic around whether the "nested" pipeline takes up >1 line?

@AshesITR
Copy link
Collaborator

> 1 line looks like a good heuristic.
Maybe better than exceptions for some functions.

@MichaelChirico
Copy link
Collaborator Author

> 1 line looks like a good heuristic. Maybe better than exceptions for some functions.

SGTM. I am thinking to make this a parameter, allow_inline = TRUE by default. FALSE is the current logic, TRUE only hits when the "inner" pipeline spans >1 line

@AshesITR AshesITR merged commit 8414018 into main Nov 20, 2023
@MichaelChirico MichaelChirico deleted the nested_pipe_linter branch November 20, 2023 06:38
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