We recommend using Visual Studio 2017

CA1051: Do not declare visible instance fields


The new home for Visual Studio documentation is Visual Studio 2017 Documentation on docs.microsoft.com.

The latest version of this topic can be found at CA1051: Do not declare visible instance fields.

|Breaking Change|Breaking|

An externally visible type has an externally visible instance field.

The primary use of a field should be as an implementation detail. Fields should be private or internal and should be exposed by using properties. It is as easy to access a property as it is to access a field, and the code in the accessors of a property can change as the features of the type expand without introducing breaking changes. Properties that just return the value of a private or internal field are optimized to perform on par with accessing a field; very little performance gain is associated with the use of externally visible fields over properties.

Externally visible refers to public, protected, and protected internal (Public, Protected, and Protected Friend in Visual Basic) accessibility levels.

To fix a violation of this rule, make the field private or internal and expose it by using an externally visible property.

Do not suppress a warning from this rule. Externally visible fields do not provide any benefits that are unavailable to properties. Additionally, public fields cannot be protected by Link Demands. See CA2112: Secured types should not expose fields.

The following example shows a type (BadPublicInstanceFields) that violates this rule. GoodPublicInstanceFields shows the corrected code.

using System;

namespace DesignLibrary
   public class BadPublicInstanceFields
      // Violates rule DoNotDeclareVisibleInstanceFields.
      public int instanceData = 32;

   public class GoodPublicInstanceFields
      private int instanceData = 32;

      public int InstanceData
         get { return instanceData; }
         set { instanceData = value ; }

CA2112: Secured types should not expose fields

Link Demands