Click to Rate and Give Feedback
MSDN
MSDN Library
Visual Studio 2008
Development Edition
Design Warnings
 Properties should not be write only

  Switch on low bandwidth view
This page is specific to
Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:
Visual Studio Team System
Properties should not be write only

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.

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 What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Forbidding write-only property effectively breaks good test-driven-development      scottnelsonsmith   |   Edit   |   Show History

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.

Flag as ContentBug
The rule is correct. Write-only properties breaks good test-driven development      dale6   |   Edit   |   Show History
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 What's this?: Add a tag
Flag as ContentBug
Processing
© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker