Gendarme.Rules.Xamarin/lib/Gendarme.Rules.Maintainabil...

313 строки
14 KiB
XML

<?xml version="1.0"?>
<doc>
<assembly>
<name>Gendarme.Rules.Maintainability</name>
</assembly>
<members>
<member name="T:Gendarme.Rules.Maintainability.AvoidAlwaysNullFieldRule">
<summary>
A type has a private field whose value is always null.
</summary>
<example>
Bad example:
<code>
internal sealed class Bad {
private List&lt;int&gt; values;
public List&lt;int&gt; Values {
get {
return values;
}
}
}
</code></example>
<example>
Good example:
<code>
internal sealed class Good {
private List&lt;int&gt; values = new List&lt;int&gt;();
public List&lt;int&gt; Values {
get {
return values;
}
}
}
</code></example>
<remarks>This rule is available since Gendarme 2.4</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.AvoidComplexMethodsRule">
<summary>
This rule computes the cyclomatic complexity (CC) for every method and reports any method
with a CC over 25 (this limit is configurable). Large CC value often indicate complex
code that is hard to understand and maintain. It's likely that breaking the
method into several methods will help readability. This rule won't report any defects
on code generated by the compiler or by tools.
</summary>
<remarks>This rule is available since Gendarme 2.0</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidComplexMethodsRule.SuccessThreshold">
<summary>The cyclomatic complexity at which defects begin to be reported.</summary>
<remarks>This defaults to 25 and larger values will mean fewer reported defects.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidComplexMethodsRule.LowThreshold">
<summary>Methods with cyclomatic complexity less than this will be reported as low severity.</summary>
<remarks>If left as zero then the rule will initialize it to 2*SuccessThreshold.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidComplexMethodsRule.MediumThreshold">
<summary>Methods with cyclomatic complexity less than this (but higher than LowThreshold) will be reported as medium severity.</summary>
<remarks>If left as zero then the rule will initialize it to 3*SuccessThreshold.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidComplexMethodsRule.HighThreshold">
<summary>Methods with cyclomatic complexity less than this (but higher than MediumThreshold) will be reported as high severity.</summary>
<remarks>Methods with cyclomatic complexity greater than this will be reported as critical severity.
If left as zero then the rule will initialize it to 4*SuccessThreshold.</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.AvoidDeepInheritanceTreeRule">
<summary>
This rule will fire if a type has (by default) more than four base classes defined
within the assembly set being analyzed. Optionally it will also count base
classes defined outside the assembly set being analyzed.
</summary>
<remarks>This rule is available since Gendarme 2.0</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidDeepInheritanceTreeRule.MaximumDepth">
<summary>Classes with more base classes than this will result in a defect.</summary>
<remarks>Defaults to 4.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidDeepInheritanceTreeRule.CountExternalDepth">
<summary>If true the rule will count base classes defined outside the assemblies being analyzed.</summary>
<remarks>Defaults to false.</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.AvoidLackOfCohesionOfMethodsRule">
<summary>
This rule checks every type for lack of cohesion between the fields and the methods. Low cohesion is often
a sign that a type is doing too many, different and unrelated things. The cohesion score is given for each defect
(higher is better).
Automatic properties (e.g. available in C# 3) are considered as fields since their 'backing field' cannot be
directly used and the getter/setter is only used to update a single field.
</summary>
<remarks>This rule is available since Gendarme 2.0</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidLackOfCohesionOfMethodsRule.SuccessLowerLimit">
<summary>Cohesion values lower than this will result in a defect.</summary>
<remarks>Defaults to 0.5.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidLackOfCohesionOfMethodsRule.LowSeverityLowerLimit">
<summary>Defects with cohesion values greater than this will be reported at low severity.</summary>
<remarks>Defaults to 0.4.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidLackOfCohesionOfMethodsRule.MediumSeverityLowerLimit">
<summary>Defects with cohesion values greater than (but less than LowSeverityLowerLimit) this will be reported at medium severity.</summary>
<remarks>Defaults to 0.2.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidLackOfCohesionOfMethodsRule.MinimumMethodCount">
<summary>The minimum number of methods a class must have to be checked.</summary>
<remarks>Defaults to 2.</remarks>
</member>
<member name="P:Gendarme.Rules.Maintainability.AvoidLackOfCohesionOfMethodsRule.MinimumFieldCount">
<summary>The minimum number of fields a class must have to be checked.</summary>
<remarks>Defaults to 1.</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.AvoidUnnecessarySpecializationRule">
<summary>
This rule checks methods for over specialized parameters - i.e. parameter types
that are unnecessarily specialized with respect to what the method needs to
perform its job. This often impairs the reusability of the method. If a problem
is found the rule will suggest the most general type, or interface, required for the
method to work.
</summary>
<example>
Bad example:
<code>
public class DefaultEqualityComparer : IEqualityComparer {
public int GetHashCode (object obj)
{
return o.GetHashCode ();
}
}
public int Bad (DefaultEqualityComparer ec, object o)
{
return ec.GetHashCode (o);
}
</code></example>
<example>
Good example:
<code>
public class DefaultEqualityComparer : IEqualityComparer {
public int GetHashCode (object obj)
{
return o.GetHashCode ();
}
}
public int Good (IEqualityComparer ec, object o)
{
return ec.GetHashCode (o);
}
</code></example>
<remarks>This rule is available since Gendarme 2.0</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.ConsiderUsingStopwatchRule">
<summary>
This rule checks methods for cases where a <c>System.Diagnostics.Stopwatch</c> could be
used instead of using <c>System.DateTime</c> to compute the time required for an action.
Stopwatch is preferred because it better expresses the intent of the code and because (on
some platforms at least) StopWatch is accurate to roughly the microsecond whereas
DateTime.Now is only accurate to 16 milliseconds or so. This rule only applies to assemblies
compiled with the .NET framework version 2.0 (or later).
</summary>
<example>
Bad example:
<code>
public TimeSpan DoLongOperation ()
{
DateTime start = DateTime.Now;
DownloadNewOpenSuseDvdIso ();
return DateTime.Now - start;
}
</code></example>
<example>
Good example:
<code>
public TimeSpan DoLongOperation ()
{
Stopwatch watch = Stopwatch.StartNew ();
DownloadNewOpenSuseDvdIso ();
return watch.Elapsed;
}
</code></example>
<remarks>This rule is available since Gendarme 2.0</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.PreferStringIsNullOrEmptyRule">
<summary>
This rule checks methods for cases where <c>String.IsNullOrEmpty</c> could be
used instead of doing separate null and length checks. This does not affect
execution nor performance (much) but it does improve source code readability.
This rule only applies to assemblies compiled with .NET 2.0 (or later).
</summary>
<example>
Bad example:
<code>
public bool SendMessage (string message)
{
if ((message == null) || (message.Length == 0)) {
return false;
}
return SendMessage (Encode (message));
}
</code></example>
<example>
Good example:
<code>
public bool SendMessage (string message)
{
if (String.IsNullOrEmpty (message)) {
return false;
}
return SendMessage (Encode (message));
}
</code></example>
<remarks>This rule is available since Gendarme 2.0</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.RemoveDependenceOnObsoleteCodeRule">
<summary>
This rule will warn you if your code depends on (e.g. inherit, implement, call...)
code that is decorated with the <c>[Obsolete]</c> attribute.
Note that the rule does not report <c>[Obsolete]</c> types, methods...
but only their use by your code.
</summary>
<example>
Bad example:
<code>
[Obsolete ("Limited to In32.MaxValue, use new Int64 ReportAll method")]
abstract int Report (IList list);
abstract long ReportAll (IList list);
public int GetCount ()
{
// this method is not ok since it use an obsolete method
return Report (list);
}
</code></example>
<example>
Good example (dependency removed):
<code>
[Obsolete ("Limited to In32.MaxValue, use new Int64 ReportAll method")]
abstract int Report (IList list);
abstract long ReportAll (IList list);
// this method is correct but this changed the public API
public long GetCount ()
{
return ReportAll (list);
}
</code></example>
<example>
Good example (decorated as [Obsolete]):
<code>
[Obsolete ("Limited to In32.MaxValue, use new Int64 ReportAll method")]
abstract int Report (IList list);
abstract long ReportAll (IList list);
[Obsolete ("Limited to In32.MaxValue, use new Int64 GetLongCount method")]
public int GetCount ()
{
// this method is now correct since it is decorated with [Obsolete]
return Report (list);
}
public long GetLongCount ()
{
return ReportAll (list);
}
</code></example>
<remarks>This rule is available since Gendarme 2.8</remarks>
</member>
<member name="T:Gendarme.Rules.Maintainability.ReviewMisleadingFieldNamesRule">
<summary>
This rule checks for fields which have misleading names, e.g. instance fields beginning with "s_"
or static fields beginning with "m_", since they can be confusing when reading source code.
</summary>
<example>
Bad example:
<code>
public class Bad {
int s_value;
static int m_other_value;
}
</code></example>
<example>
Good example:
<code>
public class Good {
int value;
static int other_value;
}
</code></example>
</member>
<member name="T:Gendarme.Rules.Maintainability.VariableNamesShouldNotMatchFieldNamesRule">
<summary>
This rule checks for local variables or parameters whose names match (case sensitive) an instance field name.
Note that variable names can only be verified when debugging symbols (pdb or mdb) are available.
</summary>
<example>
Bad example:
<code>
public class Bad {
public int value;
public void DoSomething (int value)
{
// without 'this.' the field will never be set
this.value = value;
}
}
</code></example>
<example>
Good example:
<code>
public class Good {
public int value;
public void DoSomething (int integralValue)
{
value = integralValue;
}
}
</code></example>
</member>
</members>
</doc>