Learn more about the challenges that software developers face when fields are changed to properties in C# programs. It presents an example of a code error that is difficult to discover without unit testing. This example should help the reader to avoid similar errors.

Task

The task was to change some code to accommodate new requirements. The original code looked like code below.

Listing 1.?An example of original code

The code in Listing 1 was used as follows:

Listing 2.?An example of how to use the original code

The change required the use of a new List of Integers. In order to keep language level compatibility, a property was added to return expected results in the List of Strings. The new code is in n Listing 3.

Listing 3.?An example of the modified code

Problem

The new code and client code required recompilation because instead of generated intermediate language (IL) code (Listing 4) for the listString in the original code (Listing 1), new code (Listing 5) is generated for listString as shown in the modified code (Listing 3).

Listing 4.?The IL code for listString from original code

.field private class [mscorlib]System.Collections.Generic.List`1 listString

Listing 5.?The IL code for listString from modified code

.method public hidebysig specialname instance class [mscorlib]System.Collections.Generic.List`1         get_listString() cil managed

The IL difference was caused by changing the field to the property. This change is a known breaking change that required the recompilation. After the recompilation, the code ran without issues. Later, during execution of a new unit test, some conditions triggered a failure and the incorrect behavior was caught. A call to GetCount() returned an incorrect value.

Analysis

Without running the unit test that discovered the problem, the faulty code could slip into production without being noticed.

The cause of the failure was not obvious until using Visual Studio Debugger and stepping into the properties. Line #2 on Listing 2 performs two execution steps. First, it calls the listOfStrings property getter (Note: it was a field on Listing 1) and second, it calls the Add() method. The getter returns the object it created internally and the Add() method adds the object passed to it as a parameter to the object returned by the getter. So the parameter value is added to the newly created “temporary” list. It is not added to a backing field for the property as it was in the original code. The “explicit” backing field no longer exists in the modified example.

Even though the code was recompiled to restore binary compatibility, the presented code change was a breaking change.

Conclusion

The revealed software error was easy to troubleshoot because there was access to the source code that introduced the error and the client code. The outcome would be different if the error was in a third party Dll without access to the source code.

Properties should be used only to read, write, or compute the value of a private field. The software error introduced during code modification can be fixed in different ways depending on the developers’ preference. This article demonstrates how easy it is to make mistakes during code changes and that the unit testing is essential to discovering these types of errors.

Acknowledgement

Thanks to Debie Urycki for proofreading and suggestions on corrections.

About the Author

Boris Eligulashvili is a developer at LineStream Technologies, Inc., a pioneer in embedded controls software. In his career he has worked with the latest technologies as they have evolved throughout the years from raw machine code to .NET. At present time his focus is on creating a development tool for a specific platform. Contact Boris.