-
Notifications
You must be signed in to change notification settings - Fork 30
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
Modify rule S2198: LaYC format #2156
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,3 @@ | ||
{ | ||
|
||
"quickfix": "targeted" | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,35 +1,23 @@ | ||
== Why is this an issue? | ||
|
||
Certain mathematical comparisons will always return the same value, and should simply not be made. | ||
Certain https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/comparison-operators[mathematical comparisons] will always return the same value, and should not be performed. | ||
|
||
These comparisons will return either always `true` or always `false` depending on the kind of comparison: | ||
Specifically, the following comparisons will return either always `true` or always `false` depending on the kind of comparison: | ||
|
||
* Comparing a `char` with a numeric constant that is outside of the range of `char`. | ||
* Comparing a `float` with a numeric constant that is outside of the range of `float`. | ||
* Comparing a `long` with a numeric constant that is outside of the range of `long`. | ||
* Comparing a `ulong` with a numeric constant that is outside of the range of `ulong`. | ||
* comparing a `char` with a numeric constant that is outside of the range of `char` | ||
* comparing a `float` with a numeric constant that is outside of the range of `float` | ||
* comparing a `long` with a numeric constant that is outside of the range of `long` | ||
* comparing a `ulong` with a numeric constant that is outside of the range of `ulong` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you think it would be worth it linking the msdn documentation to the types? Like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have added two links:
I have also added |
||
* etc. | ||
|
||
=== Noncompliant code example | ||
|
||
[source,csharp] | ||
---- | ||
float f = 42.0f; | ||
if (f <= double.MaxValue) { } // Noncompliant | ||
if (f <= double.MaxValue) { } // Noncompliant: always true | ||
if (f > double.MaxValue) { } // Noncompliant: always false | ||
---- | ||
|
||
ifdef::env-github,rspecator-view[] | ||
|
||
''' | ||
== Implementation Specification | ||
(visible only on this page) | ||
|
||
include::../message.adoc[] | ||
|
||
== Comments And Links | ||
(visible only on this page) | ||
|
||
=== on 31 Jan 2023, 15:54:54 Grigorios Paidis wrote: | ||
|
||
The rule is complementary to https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0652?f1url=%3FappId%3Droslyn%26k%3Dk(CS0652)[CS0652]. Thus, it only extends the functionality of this Compiler Warning. | ||
|
||
endif::env-github,rspecator-view[] | ||
include::../resources.adoc[] | ||
include::../rspecator.adoc[] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
== Resources | ||
|
||
=== Documentation | ||
|
||
* Microsoft Learn: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/comparison-operators[Comparison operators (C# reference)] | ||
* Microsoft Learn: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/integral-numeric-types#characteristics-of-the-integral-types[Ranges for integral numeric types (C# reference)] | ||
* Microsoft Learn: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/char[Range for char (C# reference)] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
ifdef::env-github,rspecator-view[] | ||
|
||
''' | ||
== Implementation Specification | ||
(visible only on this page) | ||
|
||
include::message.adoc[] | ||
|
||
== Comments And Links | ||
(visible only on this page) | ||
|
||
=== on 31 Jan 2023, 15:54:54 Grigorios Paidis wrote: | ||
|
||
The rule is complementary to https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0652?f1url=%3FappId%3Droslyn%26k%3Dk(CS0652)[CS0652]. Thus, it only extends the functionality of this Compiler Warning. | ||
|
||
endif::env-github,rspecator-view[] |
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would be the quickfix in your opinion?
Is it just removing the comparison?
I am afraid that might change the behaviour of the code. Imagine for example:
If you remove the check, the code will actually execute. Would you in this case remove also the body of the if as it was unreachable code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix would either remove the entire
if
block, or just theif
condition.For example, if the code is
if (f > double.MaxValue) Body
the entireif
would be removed.If the code is
if (f <= double.MaxValue) Body
theif
would be replaced withBody
.The same would apply to conditions like
f < double.MinValue
andf >= double.MinValue
.Indeed, there is actually the risk of changing the behavior of the code, for example in the following example:
If we would apply the code fix here, the entire
if
block would be removed, and the code would not raise an exception anymore. However, we can limit the code fix to fields only, if we want to avoid this corner case.Anyway, even if there are subtleties to be taken care of, I would keep the
targeted
, since there is a realm where in principle the code fix is possible. So I would keep the door open for now, and defer the deeper analysis to a possible future task to specify the code fix behavior.