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

Allow empty if statements if they're captured by a function #720

Merged
merged 1 commit into from
Jan 23, 2023

Conversation

Johnnei
Copy link
Contributor

@Johnnei Johnnei commented Jan 16, 2023

Fixes #229

While I don't fully agree with the presented sample, I do agree with the spirit. So a more generic solution is to ignore the If blocks entirely if they're the body of a Function (ie, they affect the return types).

@Johnnei Johnnei changed the title Allow unit results in if statement if they're captured by a function Allow empty if statements if they're captured by a function Jan 16, 2023
@codecov-commenter
Copy link

Codecov Report

Base: 87.19% // Head: 87.20% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (3e14d4f) compared to base (b7cf21d).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #720   +/-   ##
=======================================
  Coverage   87.19%   87.20%           
=======================================
  Files         141      141           
  Lines        1523     1524    +1     
  Branches      221      226    +5     
=======================================
+ Hits         1328     1329    +1     
  Misses        195      195           
Impacted Files Coverage Δ
...uel/scapegoat/inspections/empty/EmptyIfBlock.scala 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@saeltz saeltz requested a review from mccartney January 16, 2023 15:13
|import scala.concurrent.ExecutionContext.Implicits.global
|object Test {
| Future("test").map(value => {
| if (value.contains("foo")) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't have my IDE here, but I think the original authors' intent of scapegoat was to write:

Future("test").toOption match {
  case Some("foo") => ()
  case _ => throw new IllegalStateException("Bar!")
}

Does it make sense?

Copy link
Contributor Author

@Johnnei Johnnei Jan 17, 2023

Choose a reason for hiding this comment

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

Not entirely sure I follow, I based the sample on a further simplified version of the one in the issue:

  def checkFoo(things: Future[Seq[String]]): Future[Unit] = {
    things.map(ts => if (ts.contains("foo")) () else throw new Exception("No foo!"))
  }

The comment with the pattern matching is a valid workaround for this warning (although I'd prefer the transformWith solution which doesn't use flow control mechanisms), but does it really solve the problem scapegoat highlights? Instead of an empty if branch you now have an empty case branch. While empty case branches are maybe a bit more common to see, I wouldn't really see it as much different.
So I tend to agree with the the original issue and consider it a false-positive for cases where the empty branch (if or case in that regard) are being captured by the return type.

Copy link
Collaborator

Choose a reason for hiding this comment

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

does it really solve the problem scapegoat highlights

I think the intended thinking was that empty branches in ifs are not OK, but empty case is fine.
Nevertheless, I don't feel strongly about that.

Copy link
Collaborator

Choose a reason for hiding this comment

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

if @sksamuel speaks up soon, I'd let him decide.
Otherwise I am fine with merging that.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I have no strong opinion either so we can merge.

@saeltz saeltz requested a review from sksamuel January 20, 2023 07:37
@saeltz saeltz merged commit 6ac7fb0 into scapegoat-scala:master Jan 23, 2023
@saeltz
Copy link
Collaborator

saeltz commented Jan 23, 2023

Thanks for your contribution, @Johnnei!
@mccartney, should we maybe release a new patch version?

@mccartney
Copy link
Collaborator

2.1.1 has been released.

@Johnnei Johnnei deleted the monadic-if branch February 1, 2023 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

False positive "Empty if statement"
5 participants