|
|
Rule
|
Description
|
Automatic Correction
|
|
ISerializable Types Should be Marked Serializable
|
Even though a class implements ISerializable the runtime will raise a
SerializationException if any of the objects in the graph are not marked
Serializable. Therefore all classes that support the ISerializable
interface should be marked Serializable with an attribute.
.NET Usage Knowledge Pack
|
Yes
|
| ISerializable Type must implement serializable
constructor |
Serializable
classes require a constructor that can be used to construct object from the
serialization information. At deserialization time a constructor with the
signature ClassName(SerializationInfo info, StreamingContext context) is called
to create the class. Although failure to implement this constructor will create
a runtime error, the compiler does not catch the problem.
.NET Usage Knowledge Pack |
Yes
|
| Objects that implement ISerializable implement
Add/GetValue for all fields |
Objects that
implement ISerializable should fully implement the serialization constructor
and GetObjectData method by deserializing or serializing all fields.
.NET Usage
Knowledge Pack
|
Yes
|
| Unused Method Argument |
A method
declaration contains an argument that is not used within the method. This
should be addressed by removing the argument or implementing its use.
.NET Usage
Knowledge Pack
|
No
|
| Abstract Types Should Not Have Public
Constructors |
By design abstract classes are used to provide an empty or partial
implementation of a type and meant for subclasses to implement the remaining
functionality. They can never be implemented. Therefore the
recommended design pattern for doing this is to never create public
constructors for your abstract class.
Design Knowledge Pack
|
Yes
|
| Do Not Allow Inheritance Of Custom Attributes |
Attribute classes should inherit directly from System.Attribute and should
therefore be protected from further inheritance.
Design Knowledge Pack
|
Yes
|
| Public Fields should be Converted to Public
Properties |
To protect the
consistency of the interface and abstract direct access to member fields, it is
good practice to wrap member fields in property get/set or property get
accessors. By doing this, functionality can be added at a later point
without breaking the interface contract.
Design
Knowledge Pack
|
Yes
|
| Do not create methods that throw System.Exception |
System.Exception is a base class for subclassing all
exceptions and should therefore not be used directly.
Error Handling Knowledge Pack |
Yes
|
| Do not create methods that throw
System.NullReferenceException |
System.NullReferenceException is a system exception thrown
only by the runtime and should not be thrown by application code.
Error Handling Knowledge Pack
|
Yes
|
| Do not create methods that throw
System.Runtime.InteropServices.ExternalException |
ExternalException is a base class for subclassing COM
Interop exceptions from and should therefore not be thrown directly.
Error Handling Knowledge Pack
|
Yes
|
| Do not create methods that throw
System.SystemException |
System.SystemException is a base class for
subclassing all system exceptions and should therefore not be thrown
directly.
Error Handling Knowledge Pack
|
Yes
|
| Do not create methods that throw
System.IndexOutOfRangeException |
System.IndexOutOfRangeException
is a system exception thrown only by runtime and should not be thrown by
application code. Other more appropriate exceptions should be thrown such as
ArgumentOutOfRangeException, InvalidOperationException, or
ApplicationException.
Error Handling Knowledge Pack
|
Yes
|
| Method parameters should be camel case |
Method parameter names should use a camel case for their names
Naming Conventions Knowledge Pack
|
Yes
|
| Test For Empty Strings Using String Length |
Test for empty strings using string length, not string.empty or "" to get the
best performance.
Performance Knowledge Pack
|
Yes
|
|
Lock Must not be Obtained on a Value Type.
|
Montor.Enter() and Exit() calls must lock on an object of a
reference type. They should never lock on an object of a value type such as
object of type "int". Unlike the lock statement, the compiler will allow you to
acquire a lock on an object of a value type.
|
No
|
|