On the Evolution of .NET Technical Documentation and Naming Conventions

This article is not about technology; it is simply about two things that happened a long time ago, but which I only discovered a few months ago.

The Disappearance of the MSDN Platform

In the past, .NET technical documentation was primarily centralized on MSDN (Microsoft Developer Network), a platform that provided developers with API references, tutorials, and sample code.

In my notes from just a few months ago, I can still see myself using "MSDN" to refer to .NET documentation. It was only a few months ago that I noticed the MSDN website no longer uses the term msdn. After looking into it, I discovered that MSDN has been retired, its content migrated to Microsoft Docs, and the platform has since been rebranded as Microsoft Learn.

Both "MSDN Code Gallery has been retired" and "Updates to the migration of MSDN and TechNet to docs.microsoft.com" explain this transition. If you want to search for older versions of .NET documentation, you can find them in ".NET Previous Versions". However, because the documentation update strategy is split between versions prior to .NET Framework 4 and the continuously updated latest versions, some older information may no longer be complete.

Changes in Field Naming Conventions

Around June, while discussing naming conventions at work, I mentioned that there was currently no standard requiring private fields to use an _ prefix. I was immediately proven wrong. The current Microsoft documentation, "C# Identifier Naming Rules and Conventions", states:

Private instance fields start with an underscore (_) and the rest of the text is camelCased.

Upon further reflection, I realized that in official samples from the last two years, private fields have indeed started using the _ prefix.

After doing some research, I have to say that early .NET documentation is becoming increasingly difficult to find. It took a long time to locate this post: "Internal Coding Guidelines".

Do not use a prefix for member variables (, m, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

But why has it changed to using the _ prefix now? According to the guidelines proposed by .NET Core in 2016, ".NET CoreFX - C# Coding Style":

We use camelCase for internal and private fields and use readonly where possible. Prefix instance fields with , static fields with s and thread static fields with t. When used on static fields, readonly should come after static (i.e. static readonly not readonly static).

This is the exact opposite of the early .NET Framework naming conventions. At that time, the use of prefixes for private fields was discouraged. However, the .NET CoreFX team believed this naming style was easier to maintain. Consequently, with the merger of .NET Core and .NET Framework, .NET 5 unified these style guides and gradually promoted the convention of using the _ prefix for private fields across all samples.

Now, .NET source code and many open-source projects follow this naming convention. I feel like I've stepped into a parallel universe, as my understanding until this year was still stuck on the version without prefixes XD. Compared to the early .NET Framework era, modern .NET Core code style is much more consistent. If you are interested, you can check the Reference Source; the private fields there are a chaotic mix of no prefix, _ prefix, and m_ prefix.

Change Log

• 2024-09-20 Initial document created.