TypeName
PropertiesShouldNotBeWriteOnly
CheckId
CA1044
Category
Microsoft.Design
Breaking Change
Breaking
The public or protected property has a set accessor but does not have a get accessor.
Get accessors provide read access to a property and set accessors provide write access. While it is acceptable and often necessary to have a read-only property, the design guidelines prohibit using write-only properties because allowing a user to set a value, and then preventing the user from viewing the value does not provide any security. Also, without read access, the state of shared objects cannot be viewed, which limits their usefulness.
To fix a violation of this rule, add a get accessor to the property. Alternatively, if the behavior of a write-only property is necessary, consider converting this property to a method.
It is strongly recommended that you do not suppress a warning from this rule.
In the following example, BadClassWithWriteOnlyProperty is a type with a write-only property. GoodClassWithReadWriteProperty contains the corrected code.
Imports System Namespace DesignLibrary Public Class BadClassWithWriteOnlyProperty Dim someName As String ' Violates rule PropertiesShouldNotBeWriteOnly. WriteOnly Property Name As String Set someName = Value End Set End Property End Class Public Class GoodClassWithReadWriteProperty Dim someName As String Property Name As String Get Return someName End Get Set someName = Value End Set End Property End Class End Namespace
using System; namespace DesignLibrary { public class BadClassWithWriteOnlyProperty { string someName; // Violates rule PropertiesShouldNotBeWriteOnly. public string Name { set { someName = value; } } } public class GoodClassWithReadWriteProperty { string someName; public string Name { get { return someName; } set { someName = value; } } } }
This rule disables the write property in test-driven-design where it can (and should) be used to set up (i.e. "dependency inject" or "inversion of control") the associations among objects. Development teams that enforce this rule will have a very difficult time setting up effective unit testing.
Substituting using a method here eviscerates the whole meaning of properties.
In a test-driven-development environment, this rule would have to be disabled always.
My objection to this rule would be substantially "mollified" if this rule only complained when the type of the property was a primitive. Using write-only properties in test-driven-development always involves complex objects.