Edited the DoNotUseReservedInEnumValueNamesRule,

AvoidDeepNamespaceHierarchyRule, and
ParameterNamesShouldMatchOverridenMethodRule
descriptions.


svn path=/trunk/mono-tools/; revision=140938

4 files changed, 19 insertions, 14 deletions

diff --git a/gendarme/rules/Gendarme.Rules.Naming/AvoidDeepNamespaceHierarchyRule.cs b/gendarme/rules/Gendarme.Rules.Naming/AvoidDeepNamespaceHierarchyRule.cs
index 7d6bdadb..e813b864 100644
--- a/gendarme/rules/Gendarme.Rules.Naming/AvoidDeepNamespaceHierarchyRule.cs
+++ b/gendarme/rules/Gendarme.Rules.Naming/AvoidDeepNamespaceHierarchyRule.cs
@@ -27,6 +27,7 @@
 //
 
 using System;
+using System.ComponentModel;
 
 using Mono.Cecil;
 
@@ -36,8 +37,6 @@ using Gendarme.Framework.Helpers;
 
 namespace Gendarme.Rules.Naming {
 
-	// TODO: Can users really change the default?
-
 	/// <summary>
 	/// This rule checks for deeply nested namespaces within an assembly. It will
 	/// warn if the depth is greater than four (default value) unless the fifth (or the
@@ -89,8 +88,13 @@ namespace Gendarme.Rules.Naming {
 	[EngineDependency (typeof (NamespaceEngine))]
 	public class AvoidDeepNamespaceHierarchyRule : Rule, IAssemblyRule {
 
-		private int max_depth = 4; // default value
+		private const int DefaultMaxDepth = 4;
+		private int max_depth = DefaultMaxDepth;
 
+		/// <summary>The depth at which namespaces may be nested without triggering a defect.</summary>
+		/// <remarks>Defaults to 4.</remarks>
+		[DefaultValue (DefaultMaxDepth)]
+		[Description ("The depth at which namespaces may be nested without triggering a defect.")]
 		public int MaxDepth {
 			get { return max_depth; }
 			set {
diff --git a/gendarme/rules/Gendarme.Rules.Naming/ChangeLog b/gendarme/rules/Gendarme.Rules.Naming/ChangeLog
index a8b33e50..8f664060 100644
--- a/gendarme/rules/Gendarme.Rules.Naming/ChangeLog
+++ b/gendarme/rules/Gendarme.Rules.Naming/ChangeLog
@@ -1,3 +1,8 @@
+2009-08-30  Jesse Jones  <jesjones@mindspring.com>
+
+	* DoNotUseReservedInEnumValueNamesRule.cs, AvoidDeepNamespaceHierarchyRule.cs
+	ParameterNamesShouldMatchOverridenMethodRule.cs: Edited the rule descriptions.
+
 2009-07-28  Cedric Vivier  <cedricv@neonux.com>
 
 	UseCorrectSuffixRule.cs: Lower the confidence when the base type itself does not use correct suffix
diff --git a/gendarme/rules/Gendarme.Rules.Naming/DoNotUseReservedInEnumValueNamesRule.cs b/gendarme/rules/Gendarme.Rules.Naming/DoNotUseReservedInEnumValueNamesRule.cs
index bda734cd..3481993b 100644
--- a/gendarme/rules/Gendarme.Rules.Naming/DoNotUseReservedInEnumValueNamesRule.cs
+++ b/gendarme/rules/Gendarme.Rules.Naming/DoNotUseReservedInEnumValueNamesRule.cs
@@ -33,14 +33,11 @@ using Gendarme.Framework.Rocks;
 
 namespace Gendarme.Rules.Naming {
 
-	// TODO: How is renaming a reserved enum a breaking change, but adding a new
-	// enum is not?
-
 	/// <summary>
 	/// This rule checks for enumerations that contain values named <c>reserved</c>. This
-	/// practice, often seen in C/C++ applications, is not needed in .NET since adding new
-	/// values is (normally) not a breaking change. However renaming a <c>reserved</c> value to a new
-	/// name would be a breaking change.
+	/// practice, often seen in C/C++ sources, is not needed in .NET since adding new
+	/// values will not normally break binary compatibility. However renaming a <c>reserved</c> 
+	/// enum value can since there is no way to prevent people from using the old value.
 	/// </summary>
 	/// <example>
 	/// Bad example:
diff --git a/gendarme/rules/Gendarme.Rules.Naming/ParameterNamesShouldMatchOverridenMethodRule.cs b/gendarme/rules/Gendarme.Rules.Naming/ParameterNamesShouldMatchOverridenMethodRule.cs
index 68fbfa0f..fa703684 100644
--- a/gendarme/rules/Gendarme.Rules.Naming/ParameterNamesShouldMatchOverridenMethodRule.cs
+++ b/gendarme/rules/Gendarme.Rules.Naming/ParameterNamesShouldMatchOverridenMethodRule.cs
@@ -35,13 +35,12 @@ using Gendarme.Framework.Rocks;
 
 namespace Gendarme.Rules.Naming {
 
-	// TODO: This really needs to explain why this is a problem. Is it just the potential for a
-	// bit of confusion as the FxCop rule suggests or are there more serious problems with
-	// languages like VB? 
-
 	/// <summary>
 	/// This rule warns if an overriden method's parameter names does not match those of the 
-	/// base class or those of the implemented interface.
+	/// base class or those of the implemented interface. This can be confusing because it may
+	/// not always be clear that it is an override or implementation of an interface method. It
+	/// also makes it more difficult to use the method with languages that support named
+	/// parameters (like C# 4.0).
 	/// </summary>
 	/// <example>
 	/// Bad example: