org.sonar.plugins.csharp.S1104.html Maven / Gradle / Ivy
Why is this an issue?
Public fields in public classes do not respect the encapsulation principle and have three main disadvantages:
- Additional behavior such as validation cannot be added.
- The internal representation is exposed, and cannot be changed afterwards.
- Member values are subject to change from anywhere in the code and may not meet the programmer’s assumptions.
To prevent unauthorized modifications, private attributes and accessor methods (set and get) should be used.
Note that due to optimizations on simple properties, public fields provide only very little performance gain.
What is the potential impact?
Public fields can be modified by any part of the code and this can lead to unexpected changes and hard-to-trace bugs.
Public fields don’t hide the implementation details. As a consequence, it is no longer possible to change how the data is stored internally without
impacting the client code of the class.
The code is harder to maintain.
Exceptions
Fields marked as readonly or const are ignored by this rule.
Fields inside classes or structs annotated with [StructLayout] are ignored by this rule.
Fields inside classes or structs annotated with [Serializable] are ignored by this rule unless they are annotated with
[NonSerialized].
How to fix it
Depending on your needs:
- Use auto-implemented properties:
For common cases, where no validation is required, auto-implemented properties are a good alternative to
fields: these allows fine grained access control and offers the flexibility to add validation or change internal storage afterwards. Note:
as a bonus it is now possible to monitor value changes using breakpoints.
- Encapsulate the fields in your class. To do so:
- Make the field private.
- Use public properties (set and get) to access and modify the field.
- Mark field as
readonly or const.
Code examples
Noncompliant code example
public class Foo
{
public int InstanceData = 32; // Noncompliant
public int AnotherInstanceData = 32; // Noncompliant
}
Compliant solution
public class Foo
{
// using auto-implemented properties
public int InstanceData { get; set; } = 32;
// using field encapsulation
private int _anotherInstanceData = 32;
public int AnotherInstanceData
{
get { return _anotherInstanceData; }
set
{
// perform validation
_anotherInstanceData = value;
}
}
}
Pitfalls
Please be aware that changing a field by a property in a software that uses serialization could lead to binary incompatibility.
Resources