This rule states: “There is no good reason to create a new object to not do anything with it.”
I generally agree with the idea behind this rule, the problem is when you run into poorly designed APIs that have constructors that have side effects. The rule says to change the constructor to not have side effects, but that is not possible if the API is, for example, a web standard you have no control over like the Notification API Notification - Web APIs | MDN . In this API simply doing
new Notification('msg') will actually send the notification. I don’t know how such terrible design got codified as a web standard, but it did, and to use this API, you have no choice but to violate this rule.
Therefore, this rule should have a list of exceptions for very common APIs with constructors that have side effects. Specifically, APIs that are widely accepted web standards like the Notification API.
Thank you for bringing this up. We’ll look into this one!
For future reference, here’s a link to rule S1848.
Thank you for the feedback,
Indeed this use case should be implemented as an exception to the S1848 rule and not be flagged as an issue.
We created a Ticket to track this false positive.
We are running into the same issue with this:
Linear Progress component that is part of Material Design? Or is it something else?
According to their documentation, one needs to keep the instance into a variable to be able to set progress with a method. Are you doing something different?
[gabriel.vivas] Your assumption is correct.
MDCLinearProgress IS the linear progressbar from the Material Components Library.
We use the indeterminate linear progress quite a lot, just to indicate that a background process has started (we don’t necessarily need a constant).
I can imagine though that some folks would like to use the API.
For instance when one would like to display the percentage proceeded in a position of their choosing in the design (e.g.
I think [Ilia_Kebets] is right in labelling this as a false positive