Design Warnings


Visual Studio Team System
Properties should not be write only

TypeName

PropertiesShouldNotBeWriteOnly

CheckId

CA1044

Category

Microsoft.Design

Breaking Change

Breaking

Cause

The public or protected property has a set accessor but does not have a get accessor.

Rule Description

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.

How to Fix Violations

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.

When to Suppress Warnings

It is strongly recommended that you do not suppress a warning from this rule.

Example

In the following example, BadClassWithWriteOnlyProperty is a type with a write-only property. GoodClassWithReadWriteProperty contains the corrected code.

Visual Basic
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
C#
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; 
         } 
      }
   }
}
Tags :


Community Content

scottnelsonsmith
Forbidding write-only property effectively breaks good test-driven-development

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.

Tags : test testing

dale6
The rule is correct. Write-only properties breaks good test-driven development
If you create a write-only property, how do you test setting it? If I set it and cannot read it, how do I test it? I disagree with scottnelsonsmith's assertion.
Tags :

Page view tracker