diff --git a/pom.xml b/pom.xml index 1e0d830fec1..3589919ee17 100644 --- a/pom.xml +++ b/pom.xml @@ -134,7 +134,7 @@ 9000000 - 8000000 + 7000000 ${project.build.directory}/${project.build.finalName}.jar diff --git a/src/main/resources/SonarLint.Runner.zip b/src/main/resources/SonarLint.Runner.zip index 22c27665b67..719c6f9825d 100644 Binary files a/src/main/resources/SonarLint.Runner.zip and b/src/main/resources/SonarLint.Runner.zip differ diff --git a/src/main/resources/org/sonar/plugins/csharp/profile.xml b/src/main/resources/org/sonar/plugins/csharp/profile.xml index 96b407126ce..22b549d3076 100644 --- a/src/main/resources/org/sonar/plugins/csharp/profile.xml +++ b/src/main/resources/org/sonar/plugins/csharp/profile.xml @@ -3,6 +3,42 @@ cs Sonar way + + csharpsquid + S3262 + + + csharpsquid + S2219 + + + csharpsquid + S3236 + + + csharpsquid + S2292 + + + csharpsquid + S3253 + + + csharpsquid + S1939 + + + csharpsquid + S2333 + + + csharpsquid + S818 + + + csharpsquid + S2275 + csharpsquid S3254 @@ -23,6 +59,10 @@ csharpsquid S1172 + + csharpsquid + S3263 + csharpsquid S3234 @@ -31,6 +71,10 @@ csharpsquid S3052 + + csharpsquid + S3246 + csharpsquid S2761 @@ -235,10 +279,6 @@ csharpsquid S125 - - csharpsquid - S2760 - csharpsquid S1862 diff --git a/src/main/resources/org/sonar/plugins/csharp/rules.xml b/src/main/resources/org/sonar/plugins/csharp/rules.xml index 68136d8bf20..226a0290eae 100644 --- a/src/main/resources/org/sonar/plugins/csharp/rules.xml +++ b/src/main/resources/org/sonar/plugins/csharp/rules.xml @@ -1,5 +1,362 @@  + + S3262 + "params" should be used on overrides + MINOR + SINGLE + + Overriding methods automatically inherit the params behavior. To ease readability, this modifier should be explicitly used in + the overriding method as well. +

+ +

Noncompliant Code Example

+
+class Base
+{
+  public virtual void Method(params int[] numbers)
+  {
+    ...
+  }
+}
+class Derived : Base
+{
+  public override void Method(int[] numbers) // Noncompliant, the params is missing.
+  {
+    ...
+  }
+}
+
+ +

Compliant Solution

+
+class Base
+{
+  public virtual void Method(params int[] numbers)
+  {
+    ...
+  }
+}
+class Derived : Base
+{
+  public override void Method(params int[] numbers)
+  {
+    ...
+  }
+}
+
+]]>
+ confusing +
+ + S2219 + "Type.IsAssignableFrom()" should not be used to check object type + MAJOR + SINGLE + + To check the type of an object there are at least three options: +
    +
  • The simplest and shortest one uses the expr is SomeType operator
  • +
  • The slightly longer typeInstance.IsInstanceOfType(expr)
  • +
  • The cumbersome and error-prone one uses expr1.GetType().IsAssignableFrom(expr2.GetType())
  • +
+

+ +

Noncompliant Code Example

+
+A expr1;
+B expr2;
+if (expr2.GetType().IsAssignableFrom(expr1.GetType())) { /* ... */ } // Noncompliant
+
+ +

Compliant Solution

+
+A expr;
+if (expr is MyType) { /* ... */ }
+
+ +or, when the type is not known at compile time: + +
+A expr;
+Type myType;
+if (myType.IsInstanceOfType(expr)) { /* ... */ }
+
]]>
+ clumsy +
+ + S3236 + Methods with caller info attributes should not be invoked with explicit arguments + MAJOR + SINGLE + + Caller information attributes (CallerFilePathAttribute, CallerLineNumberAttribute, and + CallerMemberNameAttribute) provide a way to get information about the caller of a method through optional parameters. + But the arguments for these optional parameters are only generated if they are not explicitly defined in the call. Thus, specifying + the argument values defeats the purpose of the attributes. +

+ +

Noncompliant Code Example

+
+void TraceMessage(string message,
+  [CallerMemberName] string memberName = "",
+  [CallerFilePath] string filePath = "",
+  [CallerLineNumber] int lineNumber = 0)
+{
+  /* ... */
+}
+
+void MyMethod()
+{
+  TraceMessage("my message", "MyMethod"); // Noncompliant
+}
+
+ +

Compliant Solution

+
+void TraceMessage(string message,
+  [CallerMemberName] string memberName = "",
+  [CallerFilePath] string filePath = "",
+  [CallerLineNumber] int lineNumber = 0)
+{
+  /* ... */
+}
+
+void MyMethod()
+{
+  TraceMessage("my message");
+}
+
+]]>
+ suspicious +
+ + S2292 + Trivial properties should be auto-implemented + MINOR + SINGLE + + Trivial properties, which include no logic but setting and getting a backing field should be converted to auto-implemented + properties, yielding cleaner and more readable code. +

+ +

Noncompliant Code Example

+
+public class Car
+{
+  private string _make;
+  public string Make // Noncompliant
+  {
+    get { return _make; }
+    set { _make = value; }
+  }
+}
+
+ +

Compliant Solution

+
+public class Car
+{
+  public string Make { get; set; }
+}
+
+]]>
+ clumsy +
+ + S3253 + "base()" constructor calls should not be explicitly made + MINOR + SINGLE + + Since the compiler will automatically invoke the base type's no-argument constructor, there's no need to specify its invocation explicitly. Doing so just clutters the code. +

+ +

Noncompliant Code Example

+
+class X
+{
+  public X()
+  {
+    /* ... */
+  }
+}
+
+class Y : X
+{
+  public Y(int parameter) : base() // Noncompliant
+  {
+    /* does something with the parameter */
+  }
+}
+
+ +

Compliant Solution

+
+class X
+{
+  public X()
+  {
+    /* ... */
+  }
+}
+
+class Y : X
+{
+  public Y(int parameter)
+  {
+    /* does something with the parameter */
+  }
+}
+
+]]>
+ clumsy +
+ + S1939 + Inheritance list should not be redundant + MINOR + SINGLE + + An inheritance list entry is redundant if: +
    +
  • It is Object - all classes extend Object implicitly.
  • +
  • It is int for an enum
  • +
  • It is a base class of another listed inheritance.
  • +
+ Such redundant declarations should be removed because they needlessly clutter the code and can be confusing. +

+ +

Noncompliant Code Example

+
+public class MyClass : Object  // Noncompliant
+
+enum MyEnum : int  // Noncompliant
+
+ +

Compliant Solution

+
+public class MyClass
+
+enum MyEnum
+
+]]>
+ clumsy +
+ + S2333 + Redundant modifiers should be removed + MINOR + SINGLE + + Unnecessary keywords simply clutter the code and should be removed. Specifically: +
    +
  • virtual on members of classes that are never overridden
  • +
  • partial on type declarations that are completely defined in one place
  • +
  • sealed on members of sealed classes
  • +
+

+ +

Noncompliant Code Example

+
+internal partial class MyClass // Noncompliant;
+{
+  public virtual void DoSomething()  // Noncompliant; virtual is gratuitous
+  {
+    // ...
+  }
+}
+
+ +

Compliant Solution

+
+internal class MyClass
+{
+  public void DoSomething()
+  {
+    // ...
+  }
+}
+
+]]>
+ unused +
+ + S818 + Literal suffixes should be upper case + MINOR + SINGLE + + Using upper case literal suffixes removes the potential ambiguity between "1" (digit 1) and "l" (letter el) for declaring literals. +

+ +

Noncompliant Code Example

+
+const uint a = 0u;      // Noncompliant
+const long b = 0l;      // Noncompliant
+const ulong c = 0Ul;     // Noncompliant
+const ulong d = 0uL;     // Noncompliant
+const decimal e = 1.2m;  // Noncompliant
+const float f = 1.2f;    // Noncompliant
+const double g = 1.2d;    // Noncompliant
+
+ +

Compliant Solution

+
+const uint a = 0U;
+const long b = 0L;
+const ulong c = 0UL;
+const ulong d = 0UL;
+const decimal e = 1.2M;
+const float f = 1.2F;
+const double g = 1.2D;
+
+ +

See

+
    +
  • MISRA C++:2008, 2-13-4 - Literal suffixes shall be upper case
  • +
  • MISRA C:2012, 7.3 - The lowercase character "l" shall not be used in a literal suffix
  • +
  • CERT DCL16-C - Use "L," not "l," to indicate a long value
  • +
  • CERT DCL16-CPP - Use "L," not "l," to indicate a long value
  • +
+]]>
+ cert + convention + misra + pitfall +
+ + S2275 + Format strings should be passed the correct number of arguments + CRITICAL + SINGLE + + Use fewer arguments than are expected in your format string, and you'll get an error at runtime. Use more arguments than are + expected, and you probably won't get the output you expect. Either way, it's a bug. +

+ +

Noncompliant Code Example

+
+var s1 = string.Format("{0} {1} {2}", 1, 2); // Noncompliant; too few arguments
+var s2 = string.Format("{0}", 10, 11); // Noncompliant; too many arguments
+
+ +

Compliant Solution

+
+// Pass the expected number of arguments
+var s1 = string.Format("{0} {1} {2}", 1, 2, 3);
+var s2 = string.Format("{0}", 10);
+
+or +
+// Fix the format string
+var s1 = string.Format("{0} {1}", 1, 2);
+var s2 = string.Format("{0} {1}", 10, 11);
+
+]]>
+ bug + pitfall +
S3254 Default parameter values should not be passed as arguments @@ -172,7 +529,7 @@ var x = personList ]]> bug - preformance + performance S1172 @@ -219,6 +576,49 @@ override void DoSomething(int a, int b) // no issue reported on b misra unused + + S3263 + Static fields should appear in the order they must be initialized + BLOCKER + SINGLE + + Static field initializers are executed in the order in which they appear in the class from top to bottom. Thus, + placing a static field in a class above the field or fields required for its initialization will yield unexpected + results. +

+ +

Noncompliant Code Example

+
+class MyClass
+{
+  public static int X = Y; // Noncompliant; Y at this time is still assigned default(int), i.e. 0
+  public static int Y = 42;
+}
+
+ +

Compliant Solution

+
+class MyClass
+{
+  public static int Y = 42;
+  public static int X = Y;
+}
+
+or +
+class MyClass
+{
+  public static int X;
+  public static int Y = 42;
+
+  static MyClass()
+  {
+    X = Y;
+  }
+}
+
]]>
+ bug +
S3234 "GC.SuppressFinalize" should not be invoked for types without destructors @@ -287,9 +687,55 @@ class X public object o; } + +

Exceptions

+const fields are ignored. ]]> convention
+ + S3246 + Generic type parameters should be co/contravariant when possible + CRITICAL + SINGLE + + In the interests of making code as usable as possible, interfaces and delegates with generic parameters should use the + out and in modifiers when possible to make the interfaces and delegates covariant and contravariant, + respectively. +

+

+ The out keyword can be used when the type parameter is used only as a return type in the interface or delegate. + Doing so makes the parameter covariant, and allows interface and delegate instances created with a sub-type to be used as + instances created with a base type. The most notable example of this is IEnumerable<out T>, which allows + the assignment of an IEnumerable<string> instance to an IEnumerable<object> variable, + for instance. +

+

+ The in keyword can be used when the type parameter is used only as a method parameter in the interface or a + parameter in the delegate. Doing so makes the parameter contravariant, and allows interface and delegate instances created + with a base type to be used as instances created with a sub-type. I.e. this is the inversion of covariance. The most notable + example of this is the Action<in T> delegate, which allows the assignment of an + Action<object> instance to a Action<string> variable, for instance. +

+ +

Noncompliant Code Example

+
+interface IConsumer<T>  // Noncompliant
+{
+    bool Eat(T fruit);
+}
+
+ +

Compliant Solution

+
+interface IConsumer<in T>
+{
+    bool Eat(T fruit);
+}
+
+]]>
+ api-design +
S2761 Doubled prefix operators "!!" and "~~" should not be used @@ -560,7 +1006,7 @@ MyDelegate chain23 = chain1234 - (first + fourth); // Noncompliant chain23(); // will print "1234"! -

Noncompliant Solution

+

Compliant Solution

 MyDelegate chain23 = chain1234 - first - fourth; // Compliant - "1" is first removed, followed by "4"
 
@@ -3025,14 +3471,11 @@ string s = File.ReadAllText(fileName);
   
     S2760
     Sequential tests should not check the same condition
-    CRITICAL
+    MAJOR
     SINGLE
     
-    When the same condition is checked twice in a row, it is either inefficient - why not combine the checks? - or an error -
-    some other condition should have been checked in the second test.
-

-

- This rule raises an issue when sequential ifs or switches test the same condition. + When the same condition is checked twice in a row, it is either confusing - why have separate checks? - or an error - some other condition + should have been checked in the second test.

Noncompliant Code Example

@@ -3070,10 +3513,10 @@ if (b == c)
 
 

Exceptions

- This rule ignores sequential if statements when any symbols checked in the condition is modified within - the first if. + Since it is a common pattern to test a variable, reassign it if it fails the test, then re-test it, that pattern is ignored.

]]> - bug + clumsy + suspicious S1862 diff --git a/src/main/resources/org/sonar/plugins/csharp/sqale.xml b/src/main/resources/org/sonar/plugins/csharp/sqale.xml index bf2fb37e43f..e60deb93fdf 100644 --- a/src/main/resources/org/sonar/plugins/csharp/sqale.xml +++ b/src/main/resources/org/sonar/plugins/csharp/sqale.xml @@ -1,6 +1,141 @@  + + UNDERSTANDABILITY + + S3262 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 2min + + + + + UNDERSTANDABILITY + + S2219 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 5min + + + + + DATA_RELIABILITY + + S3236 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 2min + + + + + READABILITY + + S2292 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 5min + + + + + READABILITY + + S3253 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 2min + + + + + UNDERSTANDABILITY + + S1939 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 1min + + + + + UNDERSTANDABILITY + + S2333 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 2min + + + + + UNDERSTANDABILITY + + S818 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 2min + + + + + INSTRUCTION_RELIABILITY + + S2275 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 10min + + + READABILITY @@ -76,6 +211,21 @@ + + INSTRUCTION_RELIABILITY + + S3263 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 5min + + + UNDERSTANDABILITY @@ -106,6 +256,21 @@ + + UNDERSTANDABILITY + + S3246 + + remediationFunction + CONSTANT_ISSUE + + + offset + + 5min + + + LOGIC_RELIABILITY @@ -992,7 +1157,7 @@ - LOGIC_RELIABILITY + UNDERSTANDABILITY S2760