Gendarme.Rules.Performance
From Mono
Gendarme's performance rules are located in the Gendarme.Rules.Performance.dll assembly. Latest sources are available from anonymous SVN (http://anonsvn.mono-project.com/viewcvs/trunk/mono-tools/gendarme/rules/Gendarme.Rules.Performance/) (tarball (http://anonsvn.mono-project.com/viewcvs/trunk/mono-tools/gendarme/rules/Gendarme.Rules.Performance.tar.gz?view=tar)).
Rules
AvoidReturningArraysOnPropertiesRule
Returning arrays from a property can be dangerous, because the caller doesn't know whether or it's a copy (clone) of the original or the original itself.
Bad example:
public byte[] Foo { get { return foo; } } public byte[] Bar { get { return (byte[]) bar.Clone (); } }
Good example:
public byte[] GetFoo () { return (byte[]) foo.Clone (); } public byte[] GetFoo () { return (byte[]) bar.Clone (); }
AvoidToStringOnStringsRule
NOTE: This rule is being superseded by AvoidUnneededCallsOnStringRule which checks for more similar cases.
AvoidUncalledPrivateCodeRule
This rule will check for methods that are never called. The rule will warn you if a private method isn't called in it's declaring type or an internal method doesn't have any callers in the assembly or isn't invoked by the runtime or a delegate.
Bad example:
public class MyClass { private void MakeSuff () { } public void Method () { Console.WriteLine ("Foo"); } }
Good examples:
public class MyClass { public void Method () { Console.WriteLine ("Foo"); } }
public class MyClass { private void MakeSuff () { } public void Method () { Console.WriteLine ("Foo"); MakeStuff (); } }
AvoidUninstantiatedInternalClassesRule
This rule ensures all internal classes can be instantiated. It's quite similar to the AvoidUncalledPrivateCodeRule but work for types inside an assembly.
Bad example:
internal class MyInternalClass { } public class MyClass { public void Method () { } }
In this little example, the class MyInternalClass is never instantiated.
Good example:
internal class MyInternalClass { } public class MyClass { MyInternalClass myInternalClass = new MyInternalClass (); public void Method () { } }
AvoidUnneededCallsOnStringRule
NOTE: At current time this rule is only available from our SVN repository. The next release of Gendarme will include this rule.
This rule detects when some methods, like Clone(), Substring(0), ToString() or ToString(IFormatProvider), are being called on a string instance. Since every case returns the exact same reference the extra call(s) only slow downs performance.
Bad example:
public void PrintName (string name) { Console.WriteLine ("Name: {0}", name.ToString ()); }
Good example:
public void PrintName (string name) { Console.WriteLine ("Name: {0}", name); }
AvoidUnsealedAttributesRule
This rule is used to warn the developer if both unsealed and concrete (not abstract) attribute classes are defined in the assembly. If you want other attributes to be able to derive from your attribute class, make it abstract. Otherwise, make it sealed to improve the performance.
Bad example:
[AttributeUsage (AttributeTargets.All)] public class BadAttribute : Attribute { }
Good examples:
[AttributeUsage (AttributeTargets.All)] public sealed class SealedAttribute : Attribute { }
[AttributeUsage (AttributeTargets.All)] public abstract class AbstractAttribute : Attribute { } [AttributeUsage (AttributeTargets.All)] public sealed class ConcreteAttribute : AbstractAttribute { }
AvoidUnsealedUninheritedInternalClassesRule
NOTE: At current time this rule is only available from our SVN repository. The next release of Gendarme will include this rule.
Since the JIT is able to apply more optimization to sealed types this rule checks for non-visible (outside the current assembly) and non-sealed types to find the ones that no other types inherit from.
Bad example:
// this one is correct since MyInheritedStuff inherits from this class internal class MyBaseStuff { } // this one is bad, since no other class inherit from MyConcreteStuff internal class MyInheritedStuff : MyBaseStuff { }
Good example:
// this one is correct since the class is abstract internal abstract class MyAbstractStuff { } // this one is correct since the class is sealed internal sealed class MyConcreteStuff : MyAbstractStuff { }
AvoidUnusedParametersRule
This rule is used to ensure that all parameters in the method signature are being used. There are some methods that will be skipped for this checking:
- Methods referenced by a delegate;
- Methods used as event handlers;
- Abstract methods;
- Virtual methods;
- Overriden methods; and
- External methods.
Bad example:
public void MethodWithUnusedParameters (IEnumerable enumerable, int x) { foreach (object item in enumerable) { Console.WriteLine (item); } }
Good example:
public void MethodWithUsedParameters (IEnumerable enumerable) { foreach (object item in enumerable) { Console.WriteLine (item); } }
CompareWithStringEmptyEfficientlyRule
NOTE: At current time this rule is only available from our SVN repository. The next release of Gendarme will include this rule.
This rule will check the comparison of a string variable with "" or String.Empty. This promote the use of the String.Length property. Another way to check for an empty string (and a null one at the same time) is available since the version 2.0 of the framework by using the static method String.IsNullOrEmpty.
Bad example:
public void SimpleMethod (string myString) { if (myString.Equals (String.Empty)) { } }
Good example:
public void SimpleMethod (string myString) { if (myString.Length == 0) { } }
DontIgnoreMethodResultRule
This rule detects when some code doesn't use the return value of a method call. Since any returned object potentially requires memory allocations this impacts performance.
Furthermore this often indicates that the code might not be doing what is expected. This is seen frequently on string where people forgets their immutability.
There are some special cases, e.g. StringBuilder, where some methods returns the current instance (to chain calls). The rule will ignore those well known cases.
Bad examples:
public void GetName () { string name = Console.ReadLine (); // a new trimmed string is created by never assigned to anything // but name itself is unchanged name.Trim (); Console.WriteLine ("Name: {0}", name); }
Good example:
public void GetName () { string name = Console.ReadLine (); name = name.Trim (); Console.WriteLine ("Name: {0}", name); }
EmptyDestructorRule
A type has an empty destructor or Finalize method. Unless required for API compatibility you should remove the empty destructor to reduce the GC involvment (and get better performance).
Bad example:
class Test { ~Test () { } }
Good example:
class Test { }
IDisposableWithDestructorWithoutSuppressFinalizeRule
This rule catches a common problem when a type has a destructor and implements IDisposable. In this case the Dispose method should call System.GC.SuppressFinalize to avoid the destructor to be, needlessly, called.
Bad example:
class Test: SomeClass, IDisposable { ~Test () { if (ptr != IntPtr.Zero) Free (ptr); } public void Dispose () { if (ptr != IntPtr.Zero) Free (ptr); } }
Good example:
class Test: SomeClass, IDisposable { ~Test () { if (ptr != IntPtr.Zero) Free (ptr); } public void Dispose () { if (ptr != IntPtr.Zero) Free (ptr); GC.SuppressFinalize (this); } }
MathMinMaxCandidateRule
NOTE: At current time this rule is only available from our SVN repository. The next release of Gendarme will include this rule.
This rule checks methods that seems to include code duplicating Math.Min or Math.Max functionality. The JIT can inline those methods and provide better performance compared to custom, inline, implementations.
Bad example:
int max = (a > b) ? a : b;
Good example:
int max = Math.Max (a, b);
OverrideValueTypeDefaultsRule
NOTE: At current time this rule is only available from our SVN repository. The next release of Gendarme will include this rule.
This rule checks all value types, except enumerations, to see if they use the default implementation of Equals(object) and GetHashCode() methods. While ValueType implementations can work for any value type they do so at the expense of performance (since it must reflect all fields).
You can easily override both methods with much faster code since you know all meaningful fields inside your structure. At the same time you should also provide, if your language allows it, operator overloads for equality (==) and inequality (!=).
Bad example:
public struct Coord { int X, Y, Z; }
Good example:
public struct Coord { int X, Y, Z; public override bool Equals (object obj) { if (obj == null) return false; Coord c = (Coord)obj; return ((X == c.X) && (Y == c.Y) && (Z == c.Z)); } public override int GetHashCode () { return X ^ Y ^ Z; } public static bool operator == (Coord left, Coord right) { return left.Equals (right); } public static bool operator != (Coord left, Coord right) { return !left.Equals (right); } }
UseIsOperatorRule
NOTE: At current time this rule is only available from our SVN repository. The next release of Gendarme will include this rule.
This rule checks each method to look for a complex cast operation (e.g. a as with a null check) that could be simplified using the is operator (C# syntax). Note: in some case a compiler, like [g]mcs, can optimize the code and generate IL identical to a is operator. In this case the rule will not report an error.
Bad example:
bool is_my_type = (my_instance as MyType) != null;
Good example:
bool is_my_type = (my_instance is MyType);
UseStringEmptyRule
The specified method, or property, is using the literal "" instead of String.Empty. You'll get better performance by using String.Empty.
Bad example:
string s = "";
Good example:
string s = String.Empty;
UsingStringLengthInsteadOfCheckingEmptyStringRule
NOTE: This rule is being superseded by CompareWithStringEmptyEfficientlyRule which checks for more similar cases (e.g. operators).
Feedback
Please report any documentation errors, typos or suggestions to the Gendarme Google Group (http://groups.google.com/group/gendarme). Thanks!

Powered by MediaWiki