Gendarme.Rules.Naming

Gendarme's naming rules are located in the Gendarme.Rules.Design.dll assembly. Latest sources are available from anonymous SVN (http://anonsvn.mono-project.com/viewcvs/trunk/mono-tools/gendarme/rules/Gendarme.Rules.Naming/) (tarball (http://anonsvn.mono-project.com/viewcvs/trunk/mono-tools/gendarme/rules/Gendarme.Rules.Naming.tar.gz?view=tar)).

Rules

DetectNonAlphaNumericsInTypeNamesRule

This rule ensures that the types and methods names haven't any non alphanumerical character. By convention these names should not contain any of them.

Bad example:

public class My_Custom_Class {
}

Good example:

public class MyCustomClass {
}

DoNotPrefixValuesWithEnumNameRule

This rule checks for enum values that are prefixed with the enum's name. This is typical in C application but unneeded in .NET since the enum type must be used anyway.

Bad example:

public enum Answer {
   AnswerYes,
   AnswerNo,
   AnswerMaybe,
}

Good example:

public enum Answer {
   Yes,
   No,
   Maybe
}

DoNotUseReservedInEnumValueNamesRule

It is considered bad practice to define reserved values in enums since adding new items doesn't break binary compatibility (but renaming one can). This rule warns if any value contains the word reserved.

Bad example:

public enum Answer {
   Yes,
   No,
   Maybe,
   Reserved
}

Good example:

public enum Answer {
   Yes,
   No,
   Maybe
}

EnumNotEndsWithEnumOrFlagsSuffixRule

This rule is to ensure that enumeration type namess do not end with either Enum or Flags.

Bad examples:

public enum MyCustomValueEnum {
    Foo,
    Bar 
} 
 
[Flags]
public enum MyCustomValuesFlags {
    Foo,
    Bar,
    AllValues = Foo | Bar 
}

Good examples:

public enum MyCustomValue {
    Foo,
    Bar 
} 
 
[Flags]
public enum MyCustomValues {
    Foo,
    Bar,
    AllValues = Foo | Bar 
}

ParameterNamesShouldMatchOverridenMethodRule

This rule warns if an overriden method's parameter names do not match those of the base class (or those of the implemented interface).

Bad example:

class Base {
   public abstract void Write (string text);
}
 
class SubType : Base {
   public override void Write (string output)
   {
      //...
   }
}

Good example:

class SubType : Base {
   public override void Write (string text)
   {
      //...
   }
}

UseCorrectCasingRule

This rule ensure that:

  • type names are pascal cased
  • method names are pascal cased
  • parameter names are camel cased

Bad examples:

abstract public class myClass {
   abstract public int thisMethod (int ThatParameter);
}

Good examples:

abstract public class MyClass {
   abstract public int ThisMethod (int thatParameter);
}

UseCorrectPrefixRule

This rule ensure that type are prefixed correctly. E.g. interface should start with a I and classes should not start with a C (remainder for MFC folks).

Bad examples:

public interface Phone {
}
 
public class CPhone : Phone {
}

Good examples:

public interface IPhone {
}
 
public class Phone : IPhone {
}

UseCorrectSuffixRule

This rule ensure that types that inherit from certain types, or implement some interfaces, are named correctly by appending the right suffix to them. E.g.

  • System.Attribute should end with Attribute
  • System.EventArgs should end with EventArgs
  • System.Exception should end with Exception
  • System.Collections.Queue should end with Collection or Queue
  • System.Collections.Stack should end with Collection or Stack
  • System.Data.DataSet should end with DataSet
  • System.Data.DataTable should end with DataTable or Collection
  • System.IO.Stream should end with Stream
  • System.Security.IPermission should end with Permission
  • System.Security.Policy.IMembershipCondition should end with Condition
  • System.Collections.IDictionary or System.Collections.Generic.IDictionary should end with Dictionary
  • System.Collections.ICollection, System.Collections.Generic.ICollection or System.Collections.IEnumerable should end with Collection

Bad examples:

public class SpecialCode : Attribute {}

Good examples:

public class SpecialCodeAttribute : Attribute {}

UsePluralNameInEnumFlagsRule

This rule ensure that the name of enumeration flags is in plural form.

Bad example:

[Flags]
public enum MyCustomValue {
    Foo,
    Bar,
    AllValues = Foo | Bar
}

Good example:

[Flags]
public enum MyCustomValues {
    Foo,
    Bar,
    AllValues = Foo | Bar 
}

UsePreferredTermsRule

This rule ensure that types and methods use the correct terms suggested by the .NET framework guidelines to ensure uniformity in class libraries.

  • ComPlus should be replaced with EnterpriseServices;
  • Cancelled should be replaced with Canceled;
  • Indices should be replaced with Indexes;
  • LogIn should be replaced with LogOn;
  • LogOut should be replaced with LogOff;
  • SignOn should be replaced with SignIn;
  • SignOff should be replaced with SignOut;
  • Writeable should be replaced with Writable;

Bad example:

abstract public class ComPlusSecurity {
    abstract public void LogIn ();
    abstract public void LogOut ();
}

Good example:

abstract public class EnterpriseServicesSecurity {
    abstract public void LogOn ();
    abstract public void LogOff ();
}

UseSingularNameInEnumsUnlessAreFlagsRule

The rule is used for ensure that the name of enumerations are in singular form unless the enumeration is used as flags.

Bad example:

public enum MyCustomValues {
    Foo, 
    Bar 
}

Good example:

public enum MyCustomValue {
    Foo,
    Bar 
}
 
[Flags]
public enum MyCustomValues {
    Foo,
    Bar,
    AllValues = Foo | Bar 
}

Feedback

Please report any documentation errors, typos or suggestions to the Gendarme Google Group (http://groups.google.com/group/gendarme). Thanks!