To underscore or to not to underscore, that is the question

by

IMPORTANT UPDATE (April 12, 2016):

It was brought to our attention that the internal standard of the .NET CoreFX team insists on using the underscore-notation without giving any insights as to why. However if we look closely at rule #3 it becomes evident that there is a system of _, t_, s_ prefixes that suggests why _ was chosen in the first place.

  1. 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).
  2. We avoid this. unless absolutely necessary.

So if you are just like .NET CoreFX team working on some performance critical, multithreaded, system level code, then it is STRONGLY SUGGESTED that you:

  • adhere to their coding standards and
  • use the underscore-notation and
  • don’t read this answer any further

Otherwise please read on…

THE ORIGINAL ANSWER:

Let’s first agree on what we are talking about. The question is how we access instance members from within non-static methods and constructors of a class/sub-classes if visibility modifiers allow doing so.

Underscore-notation

  • suggests that you use the “_” prefix in the names of private fields
  • it also says that you should never use “this” unless it’s absolutely necessary

This-notation

  • suggests that you just always use “this.” to access any instance member

Why does this-notation exist?

Because this is how you

  • tell apart a parameter from a field when they share the same name
  • ensure you are working in the context of the current instance

Example

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Why does the underscore-notation exist?

Some people don’t like typing “this”, but they still need a way to distinguish a field and a parameter, so they agreed to use “_” in front of a field

Example

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

One may think it’s just the matter of personal taste and both ways are equally good/bad. However there are certain aspects where this-notation beats the underscore-notation:

Clarity

  • underscore-notation clutters names
  • this-notation keeps names intact

Cognitive load

  • underscore-notation is inconsistent, it makes you treat fields in a special way, but you cannot use it with other members, every time you need to ask yourself whether you need a property or a field

  • this-notation is consistent, you don’t have to think, you just always use “this” to refer to any member

Maintenance

UPDATE: as was pointed out the following isn’t an advantage point

  • underscore-notation requires you to keep an eye on _ while refactoring, say turning a field into property (remove _) or the opposite (add _)
  • this-notation doesn’t have such problem

Autocompletion

When you need to see the list of instance members:

  • underscore-notation doesn’t help you much, because when you type “_” the autocomplete popup shows you the private fields and all types available from the linked assemblies mixed with the rest of the instance members
  • this-notation gives you a clear answer, by typing “this” all you see is the list of members and nothing else

Ambiguity

Sometimes you have to deal with the code without help of the Intellisense. For example when you do code reviews or browse source code online.

  • underscore-notation is ambiguous: When you see Something.SomethingElse you cannot tell whether Something is a class and SomethingElse is its static property… or maybe Something is a current instance property which has its own property of SomethingElse

  • this-notation is clear: When you see Something.SomethingElse it can only mean a class with a static property and when you see this.Something.SomethingElse you know that Something is a member and SomethingElse is its property

Extension methods

You cannot use extensions methods on the instance itself without using “this.”

  • underscore-notation requires that you don’t use “this”, however with the extension methods you have to
  • this-notation saves you from hesitation, you always use “this”, period.

Visual Studio support

  • underscore-notation doesn’t have a built-in support in Visual Studio

  • this-notation is supported by Visual Studio naturally:

    1. “This.” Qualification: Prefer all non-static fields used in non-static methods to be prefaced with this. in C#

Official recommendations

There a lot of official guidelines that clearly say “do not use underscores” especially in C#

  • underscore-notation came from C++ where it is a general practice which helps to avoid naming conflicts, also is recommended for VisualBasic.Net to overcome a problem where a field “value” and a property “Value” actually have the same name, because VisualBasic is case-insensitive
  1. Declared element names in Visual Basic
  2. Backing fields in VisualBasic.NET
  • this-notation is recommended for C# while “_” is explicitly prohibited:
  1. this keyword in C#
  2. Field usage guidelines: Do not apply a prefix to field names or static field names.
  3. Guidelines for names: Names of type members: Do not use a prefix for field names.
  4. General naming convention: X DO NOT use underscores, hyphens, or any other non-alphanumeric characters
  5. Quality assertion rule CA1707: Identifiers should not contain underscores
  6. Using underscores is not CLS compliant (for public and protected identifiers)
  7. Internal naming convention of .NET Framework developers: Do not use a prefix for member variables. If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

Leave a Comment

tech